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IMPROVED USER DATA PROTOCOL FOR INTERNET 
DATA COMMUNICATIONS 

CROSS REFERENCE TO RELATED APPLICATION 

This application is a continuation application of U.S. Patent Application No. 08/950,1 58. 
entitled "Improved User Data Protocol for Internet Data Communications", filed October 14, 
1997. The disclosure of the foregoing patent application is incorporated herein by reference in 
its entirety. 

FIELD OF THE INVENTION 

This invention relates to an improved user data protocol for Internet data communications 
and more particularly to a user data protocol which enables communications between computer 
systems and further enables data communications across radio networks and packet switching 
nodes. 

BACKGROUND OF THE INVENTION 

As is well known, two computer systems can communicate successfully if they recognize 
and utilize the same set of communicaion protocols. Therefore, if computers manufactured by 
differenent entities each use a different set of communication protocols designed by their 
manufactureres, these computers will not be able to communicate, A computer in principle 
could be provided with techniques for translating protocols, but it becomes extremely 
burdensome for such a computer to operate. 

As one will ascertain, most computers manufactured by any entitiy can gain access to the 
Internet or gain access to various other networks. The Internet commonly uses a standard 
protocol for interface which is referred to as the TCP/IP protocol which stands for Transmission 
Control Protocol/Internet Working Protocol. A relatively standard protocol is indicated as the 
OSI/ISO model. The term OSI stands for open system interconnection and 
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this was formulated to create a single set of standard protocols operating on the best 
features of existing practice. Therefore, use of an OSI protocol opens the possibility of 
communication between any two computer systems regardless of their origin. 

The OSI standards define only the protocols between systems and do not constrain 
the internal structures of the systems that use them. This would limit the freedom of the 
computer manufacturers to improve their designs. Thus, the same protocol may be used to 
convey information between systems with totally different internal structures and user 
interfaces. In testing that a system conforms to the published standard, only the data that 
flows between computers is considered. As one will understand, the OSI reference model 
divides the process of communication into a number of functional layers, splitting it into 
pieces that are small enough to handle and specify separately. The layers build up from the 
underlying electrical signals transmitted to a much more abstract description of the user 
activity that exploits the communication. Two types of standards are defined for each 
layer. The first is a service definition which states what the layer does on behalf of the 
layers above so that higher layers are shielded from lower layer detail. The second is the 
protocol specification which sets out how the layer performs its function and achieves the 
service by defining the messages actually exchanged and the actions taken in consequence. 

Thus, the OSIASO model provide the basis for developing communication networks. 
The OSI/ISO model identifies a seven layer architecture. Each of the layers have been 
assigned a unique role in seven layered network architecture. Typical distribution of the 
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seven layer architecture in layers 7 and 6 are application layer and unique to the 
applications that are exchanging information across the network. Layer 5 is the session 
layer, opened at the start of a data exchange, responsible for establishing connectivity to the 
distant end, closes when all data exchanges have been completed, and closed when 
5 connection to distant end is no longer required. Layer 4 is the transport layer and is 

responsible for assuring that complete messages get delivered. Layer 4 (transport layer) is 
responsible for breaking down messages into message segments that conform to the 
network datagram size constraints and is responsible for re-assembling message segments 
Q into a complete message. Layer 4 is an end to end reliability protocol normally 
10 ^ implemented in the user terminal equipment. Layer 3 (network layer) is the routing layer 
IS responsible for pushing the Datagram towards its final destination. Layer 2 (link layer) is 
Til responsible for providing communication between two or more nodes interconnected by a 
CI physical media. Layer 1 (physical) is the communication media. Layer 1 media can be 
t'^^ point to point or broadcast wire or wireless media. 
15 r:^ The basic OSI/ISO model protocol does not provide source directed multi-addressed 

message distribution. The OSI/ISO does not provide the ability to send a single multi- 
datagram message to multiple destinations via a single transmission. The OSI/ISO model 
does not provide multi-addressing of messages. The OSI/ISO implementations require 
messages sent to multiple users to be sent from the source once for each user destined to 
20 receive the information. This requires each network node to route multiple copies of the 

message through the same inter-network communication chaimel. This consumes excessive 
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communication bandwidth and congests bandwidth limited network communication 
channels. 

It is therefore an object of the present invention to provide an improved user data 
protocol which eliminates many of the above-noted problems. 

SUMMARY OF THE INVENTION 

The Improved User Data Protocol (lUDP) incorporates a multi-addressing capability. 
This allows a user to address a single message to many users. Multi-addressed messages 
that are given to the network are inserted once at the source network node. Multi-addressed 
messages routed between network nodes going to the same next node travel once across 
each interconnecting communication channel. This reduces the communication bandwidth 
consumed to a minimum. The improved data protocol can be used for data 
communications networks, consisting of wire lines, HF, VHP and UHF radios. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Figure 1 shows the IMPROVED User Data Protocol according to this invention. 
Depicting the various communication layers used in this invention. 

Figure 2A shows a connection utilizing the IMPROVED Protocol between two 

radios. 

Figure 2B shows a connection between a basic Internet communications card and a 
radio using this protocol. 
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Figure 2C shows a connection between a DCE which is a Data Communications 
Equipment and a DTE which is a Data Terminal Equipment using this protocol. 



Figure 2D depicts protocol configurations according to the IMPROVED Protocol of 
this invention. 

Figure 2E depicts a terminal interface configuration according to this invention. 

Figure 2F depicts an interface configuration according to this invention. 

Figure 3 depicts a table showing the general requirements for radio data transmission 
according to this invention. 

Figure 4 is a series of diagrams depicting the data transmission components for a 
first layer of this invention including a synch data bit stream, a data frame area, and a data 
frame. 

Figure 5 is a table showing classmarks parameters for this protocol. 
Figure 6 is a table depicting the address class and purpose of use for this protocol. 
Figure 7 is a table depicting the station classmark parameters and purposes for this 
protocol. 

Figure 8 is a table showing the protocol used in a half duplex radio communication. 
Figure 9A and 9B are tables showing link/net classmarks used in this protocol. 
Figures lOA-lOE depict Frame formats used to implement this protocol. 
Figure 11 is a table depicting the address field according to this protocol. 
Figure 12 is a table depicting the Intranet address field according this protocol. 
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Figure 13 is a table depicting a frame format according to this protocol 
Figure 14 is a table depicting a station address/number according to this protocol 
Figure 15A and 15B show a frame format and address field according to this 
protocol 

Figure 16A depicts a control field according to this protocol 

Figure 16B is a table showing an information field according to this protocol 

Figure 17A is an "S" Frame format. 

Figure 17B is an address field based on a half duplex protocol 
Figure 18 shows another example of a control field for a half duplex protocol 
Figure 19 depicts a "UI" Frame format and an address field. 
Figure 20A and 20B show Frame formats with and without an information field. 
Figure 21 shows a format of control bits for a special frame format according to this 
protocol 

Figure 22 is a table showing a bit format for each of the different modes according 
to this protocol 

Figure 23 shows a table of information field coding. 

Figure 24 is a diagram indicating the possible states between equipment according to 
this invention. 

Figure 25 is a diagram depicting a received frame and responses regarding to the 

same. 

Figure 26 is a diagram depicting an extended Internet address. 
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Figure 


27 


is 


a table depicting Internet header elements according to this protocol 




Figure 


28 


is 


a table depicting a message type/protocol 




Figure 
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is 


a table depicting a SYSCON Message type. 




Figure 
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is 


a table depicting an ICMP Message type. 
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Figure 
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is 


a table depicting a User Defined Message type. 




Figure 


32 


is 


a table showing a User Acknowledgment. 




Figure 
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is 


a table showing Encapsulated Protocols. 
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is 


a table depicting an Internet Address. 




Figure 
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is 


a table depicting a Status Byte Table. 




Figure 
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is 


a diagram showing an address entry. 




Figure 
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is 


a diagram showing an extended address entry. 




Figure 
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is 


a diagram showing an Internet address. 




Figure 
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is 


a diagram showing ICMP Message Types. 




Figure 


40 


is 


a table showing Transport Acknowledgment Message. 
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Figure 


41 


is 


a table depicting an LCCN Message. 
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is 


a table depicting the NCCN Message. 
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is 


a table depicting the ICMP Status Report Text Header. 




Figure 
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is 


a table depicting Report Text. 




Figure 


45 


is 


a table depicting an Internet Status Report Format. 
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Figure 


46 


is 


a table depicting an Internet Route Report Text. 




Figure 


47 


is 


a table depicting the Field of a message. 
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Figure 48 is a table depicting the Field of another type of message according to this 
protocol. 



DTE. 



Figure 


49 


is a table depicting a SYSCON Directive Text Header. 


Figure 


50 


is 


a table depicting a Directive Text. 


Figure 
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is 


a table depicting alarms and notifications. 


Figure 
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is 


another table depicting alarms and notification text. 


Figure 
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is 


a table showing a report text header. 


Figure 
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is 


a taDie uepiciing a repon lcxl. 


Figure 


55 


is 


a table showing a SYSCON Acknowledgment Text Header. 


Figure 


56 


is 


a table depicting an Acknowledgment Text. 


Figure 


57 


is 


a table depicting a Internet Format according to this protocol. 


r igure 


JO 


is 


a state diagram showing the connection between a DCE and a DTE. 


Figure 


59 


is 


another state diagram showing a connection between a DCE and a 


Figure 


60 


is 


a table showing an asynchronous transmission. 


Figure 


61 


is 


a table showing the IMPROVED protocols frame information field. 


Figure 


62 


is 


a table showing the IMPROVED Users Data Protocol Frame 



Information Field. 

Figure 63 is a table showing an encapsulated frame information field according to 
this protocol. 

Appendix - Table of Acronyms consisting of 4 pages. 
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DETAILED DESCRIPTION OF THE INVENTION 

The IMPROVED User Data Protocol (lUDP) provides for both full and half duplex 
data communications over synchronous and asynchronous interfaces. The full duplex 
interface is used on point-to-point links using HDLC.LAPB (Higher Data Level 
5 Communications. Link Access Procedure Balanced) procedures. The half duplex interface 
is used on both multi-point radio and point-to-point links using a modified HDLC LAPB 
procedure. Radio links or nets provide an optional relay protocol for those nets that require 
range extension due to distance or hostile interference. The relay protocols exist over the 
?f intranet address field. 

10 ^ The IMPROVED User Data Protocol is well suite for both internet radio and packet 

:i switching networks and provides BUILT-IN internet addressing and Transport Control 
. capabilities. The IMPROVED User Data Protocol consists of layers 4, 3, & 2 of the 7 
^ layer OSI/ISO model. The Physical Layer (layer 1 of the OSI/ISO model) used in figures 
Jf depicts X.21, lUDP's primary interface; however, the upper layers are designed to interact 
15 ' with various physical layers. The X.21 physical interface is used as an example because it 
is one of the Primary physical interfaces used in communication systems. 

The X.21 protocol is an extremely popular protocol which is widely known. The 
protocol provides full duplex communication across point-to-point circuits such as lead 
circuits using the higher data level communication (HDLC Protocol). The X.21 HDLC 
20 requires that the circuit be connected end to end both "C" & "I" lead inserted and a 

continuous exchange of flags before advancing from the ready state to the data transfer 
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state. Basically, the protocol has been developed for a communications data protocol and is 
widely known. The protocol uses a continuous synchronous data stream consisting of 
abort, flag, and zero inserted information characters. When the communication line is not 
transmitting information characters it is transmitting flag carriers. Zero inserted information 
characters are concatenated together to form data frames. Data frames are bounded by 
opening and closing flag characters. 

Referring to Figure 1, there is shown a diagram depicting the IMPROVED User 
Data Protocol according to this invention. As seen, the protocol follows a seven layer 
OSI/ISO model. In Figure 1 there is shown basically seven layers where layer 7 generates 
a message by a user, layer 6 the user addresses the message and builds the Internet header, 
and layer 5 which is a session layer and is not used except for Datagram service. Layer 4 
is the transport layer. In any event, as can be seen the layers that are unique to the protocol 
consists of layers 2 and 3 which will be further explained but which essentially operate as 
link layers and briefly perform the following functions. 

The layer 2 (link layer) functions are: Frame Formatting, Frame Addressing, FDX, 
HDX - Point-to-Point, Conamands and Responses, Media Access, Scheduled Access, CSMA 
(In conjunction with the radio). Frame Transfer, Link Acknowledgments, Frame 
Retransmission, and Error Detection, 

The FDX layer 2 conforms to HDLC LAPB. 

The HDX Layer 2 is a modified HDLC LAPB for random access multipoint media 
and Point-To-Point access circuits. 
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The layer 3 functions are: Layer 3A Inter-Network routing, builds the Intranet 
Header for half duplex radio interfaces, selects the proper access circuit in full and half 
duplex packet switching interfeces, Layer 3B Intra-Network routing HDX Link Layer 
Connectivity, routes to the next node within a net, provides routing data for distribution to 
other nodes on a net, processes routing data received from other nodes on a net. 

The layer 4 functions are: segment large messages into frames, interface to layer 3, 
accumulate frames from layer 3, reassemble frames into large messages, provide End-to- 
End acknowledgments for multi-frame messages. 

Internet support functions and Internet Control Message protocols provide for: 
Internet status reports, Adaptive Routing procedures and protocols, Interface protocols 
to/from the Network Management System, Congestion control protocol for internet traffic, 
Man/Machine Interface to/from user (operators). 

The lUDP is relatively independent of the radio Data Communications Equipment 
Dee and the Data Terminal Equipment DTE. 

The Radio in conjunction with a DTE provides both voice and data communications 
for Users. The radio's Layer 1 procedures are performed for both VOICE and DATA 
transmissions. 

The lUDP's Layer 2 and 3 procedures are only performed for data message 
transmissions. The protocol interacts with the radio on nets which have been voice and 
data communications. Most of this interaction is managed by the X.21 interface between 
the radio and the terminal and the relationship of the radio and terminal. 
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The lUDP'sdata service can support Data Messages up to 10,240 Bytes, 80 frames 
of 128 Bytes of actual text. Message sizes can vary by changing the frame size, the text 
size, and the maximum frame coimt in the System Classmarks. 

The "External Access Voice" messages are generated by the radio and consists of: 
Call Request, Call Accept, Call Reject, and Call Release. 

These message are received by the DTE (BICC) Basic Internet Controller Card over 
the control interface. 

Referring to Figure 2A there is shown a basic block diagram showing the connection 
of two radios or a data communication equipment terminal 20 interfacing v/ith a data 
terminal equipment 23 which may be a radio or a gateway through a BICC which is a basic 
internet controller car 21. All components are well known. The data communication 
equipment consists of a receive and transmit terminal 24 for voice and a receive and 
transmit terminal 25 for data. As can be seen, the data rates are 16 KPBS as interfacing 
with the BICC 21 and a data rates between the radio or gateway or DTE 23 can be at 16 or 
32 KPBS. 

Referring to Figure 2B, there is shown a BICC 27 coupled to a radio 26 through this 
communication path and indicating the data path as well as the control path between the 
two modules. It will be clearer how connections are implemented and how they are made 
in further discussions. 

Referring to Figure 2C, there is shown interconnections between a DCE, which is a 
data communications equipment, such as a radio and a DTE, which is a data terminal 
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equipment. Figure 2C shows all the possible configurations, as for example, between a 
terminal 30 and a DCE or radio 28 as well as between a DTE or data terminal equipment 
31 and a DCE having received transmit sections 33. Basically, as one can ascertain from 
Figure 2C, the radio is always a DC interface and operates at HDX. The terminal, such as 
terminal 30, is always a DTE interface and can operate with HDX/FDX. The BICC as 29 
or gateway has a DCE and DTE interface and therefore can operate with HDX or FDX. 
This is shown in Figure 2C which shows the DCE/DTE configurations. 

Referring to Figure 2D, there is shown protocol configurations and basically in 
Figure 2D it is seen that a radio such as module 3 1 has two data interfaces. One is control, 
which is not showTi, and the other is the X.21 data port. The BICC such as 32 processes 
the LAPB protocol on its input and regenerates the LAPB protocol on the output as seen in 
Figure 2D. This essentially shows how the protocols are accommodated. For example, on 
the right side of Figure 2D there is shown a BICC 33 which interfaces with a BICC 34. 
The protocols, as well as the interface rates are shown on the connecting lines. Similarly 
the BICC 34 interfaces with DCE 35 using the X.21 protocol Thus, the protocol format or 
protocol configurations for the various terminal equipments are shown in Figure 2D. 

Figure 2F shows the terminal interface configurations whereby terminals 40 and 41 
communicate via each other via messages and the HDLC Frame. Terminals 40 and 41 can 
communicate with the receive/transmit COMSEC, which is communication security devices, 
such as radios 42 and 43 through the LAPB X.21 Protocol as well as the units 42 and 43 
can communicate one with the other through binary data and according to this protocol. 
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The LAPB is a modified protocol for half duplex radio interfaces. The users data, as the 
data between radios 42 and 43, is binary data stream for the radio. The radios as 42 and 43 
do not have its own radio to radio protocol. The radio has a control protocol for both the 
terminal and the BICC/Gateway which is not shown. This will be described subsequently. 

Referring to Figure 2G, there is shown interface configurations which are possible 
according to the protocol to be described herein. Hence, as seen in Figure 2G a terminal 45 
can communicate with a terminal 48, terminals can communicate through BICC 46 and 49 
to respective radios as 47 and 50. The BICCs can communicate and pass control data from 
one to the other. The terminals can also provide message exchange and frame exchange 
can be provided between the various modules. The radios can interface through the BICC 
to the terminals 48 and 45 and communicate between each other through the radio sync 
data. Hence Figure 2G shows a fairly detailed interface configuration which can utilize the 
above noted protocol as will further be explained. 

Thus, Figures 2A to 2G show the various formats which can be implemented in this 
system enabling data terminal equipment to communicate with data communications 
equipment and using basic internet controller card which is a well known component. In 
this manner, the radio can communicate over land lines, point-to-point uses fiill duplex 
communications as will be explained. The attribute of making all connections as shown in 
the above noted Figures 2A to 2G is due to the improved user data protocol according to 
this invention as will be further explained. 

Voice transmissions from the DTE or radio are activated by the analog port and 
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cause the radio to generate the Voice transmission identifier (Fig 3). The radio indicates a 
BUSY condition to the data port via the X.21 "I" circuit when it is transmitting voice. 

When the radio is receiving voice, that information with a Voice identifier is 
presented to the analog port. The radio indicates a BUSY condition to the data port via the 
X.21 "I" circuit when it is receiving voice. 

Data transmission is activated by the X.21 "C" circuit. The radio performs its 
synchronization and then supplies clock to accept the data for transmission. When all the 
data has been sent to the radio for transmission the X.21 ''C" circuit is deactivated. 

The IMPROVED User Data Protocol permits multiple data frames to be transmitted 
in a single radio "transmission". 

Referring to Figure 3 there is shown a general depiction for radio data 
transmissions. It is noted that the transmission identifier which is depicted in module 60 
specifies either voice transmission from the radio or data transmission and directs the path 
of the transmission information to the data port or the voice port of the DTE. Data 
transmissions may be framed data or CVSD, which is continuous variable slope delta data 
this is a form of modulated information or voice information and one can use all different 
types of digital modulation to transmit voice. 

Digitized Voice Transmission requirements are well known and can be 
accommodated by other access protocol specifications. In any event, there are many ways 
of digitizing voice and as indicated in Figure 3 the general requirements for radio data 
transmissions are to give transmission information regarding user data frames as shown in 
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61 or telling a unit whether it is a voice transmission or data transmission as shown in 
Figure 3 by reference numeral 60. 

Referring to Figure 4 there is shown the data transmission components in the single 
radio transmission. Essentially, as seen in figure 4, layer 1 contains the data transmission 
components as indicated by module 70. These include the synch data bit stream, which is 4 
octets and a data frame area which is one to end frames. Shown beneath is the synch data 
bit stream, which is at least 4 HDLC flags and indicated by the reference numeral 71. 
Shown beneath the synch data bit stream is the data frame area which depicts the bit 
contents as for example the opening flag, the data frame, the closing flag, and the opening 
flag for the next frame all depicted in module 72. Essentially, reference numeral 73 of 
figure 4 depicts each data frame which has an address fields, a control field, an information 
field, and an FCS (Frame Check Sequence). 

During radio data reception, the data transmission are presented to the data port of 
the radio with clocks while activating the X.21 "I" circuit. The DTE receives the data 
while the clocks are present. When the data has been transferred from the radio to the DTE 
the clocks and the X.21 circuit are deactivated to inform the DTE that all the data has 
been transferred, 

RADIO DATA RECEPTION 

Data transmissions are presented to the data port with clocks while activating the 
X.21 "I" circuit. The DTE receives the data while clocks are present. When the data has 
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been transferred from the radio to the DTE the clocks and the X.21 "I" circuit are 
deactivated to inform the DTE that all the data has been transferred. 

The IMPROVED User Data Protocol enables a User Data Terminal (UDT) to 
communicate with another Terminal using VHF/HF Combat Net Radios in a point-to-point, 
in a radio Net, or across radio Nets. In addition, data communications can also be 
transmitted across packet switching nodes, such as Internet Gateways or other switching 
backbone systems. The IMPROVED User Data Protocol specifies both the half duplex and 
full duplex link layer protocols, as well as the Network and Transport layer protocols. 

The IMPROVED User Data Protocol enables data communications in combined 
Voice/Data radio nets. The Voice issues are not addressed in this specification, however 
^ the radio is assumed to indicate that the net is busy with voice traffic through the data 
^ interface. 

The concept of INTERNET communications for data is supported with the use of 
Internet Points (LP.)- Internet Points are defined as dual radios with a BICC applique or a 
gateway which is connected to multiple radios and/or multiple BICCs. These Internet 
Points also support directly connected user terminals. 

The Radio and the User Data Terminal (UDT) or a BICC applique and terminal are 
referred to as a STATION. The station acts as a collective and provides the 
features/functions of lUDP. 

To provide both voice and data transmissions the radio indicates the transmission 
type. Analog voice transmission normally originate and terminate at the radio's audio port. 
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Data transmissions normally originate and terminate at the dat port (X.21). Digital voice 
originate and terminate at the data port (X.21) when providing External Access. 

Access Circuit Layer 1 processing is accommodated by dedicated point-to-point 
circuits which are full or half duplex and provide communications between two combined 
stations using balanced link control capabilities. 

The half duplex protocol for the radio layer 2 processing uses the HDLC frame. 
There are three modes of the half duplex protocol, the "ALL-INFORMED'' mode, the 
"RELAY" mode, and the point-to-point mode. The ALL-INFORMED mode uses the 
Intranet header which specifies the station(s) that are to receive the frame. The "RELAY" 
mode adds the link layer relay header to the frame which specifies those stations that are to 
receive and/or relay the frame to other stations. The network can run with any combination 
of "ALL-INFORMED" and "RELAY" nets. The point-to-point mode uses the same 
procedures and frame structures as the radio modes, however, it does not use either the 
Intranet or Relay headers. It does use the address field as specified in the full duplex 
protocol (the command and response address). This layer 2 can use either a 16 or 32 bit 
FCS on synchronous interfaces. 

Access Circuit Layer 2 processing is accommodated by the full duplex layer 2 
protocol uses the HDLC LAPB protocol. This layer 2 is restricted to the basic mode 
(modulo 8), does not use the SREJ (selective reject), and uses a 16 or 32 bit FCS. The half 
duplex protocol uses HDLC and a modified form of LAPB. 

The Layer 3 is divided into two sub-layers, the internet layer 3A and the intranet 
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relay layer 3B (Fig. 1). Layer 3A performs the routing of Internet Addresses to; local users 
or functional entities, to radio nets, or to directly connected point-to-point nodes. 

The Layer 3 A Processing first performs routing of the internet addresses in the 
internet header. For half duplex radio nets this routing process builds a list of stations on 
the "home" net in the intranet header. Addresses which belong to other net are either sent 
to an Internet Router or to an Internet Point, 

For access circuits the addresses are placed in a list for each circuit. When routing 
is complete, a new Internet Header is built for each circuit using its addresses. 

A complete description of the Internet Header, address structures, and routing 
concepts will be given. 

Layer 3B processing is only performed for radio nets which are classmarked as 
"Relay" nets. When active, this layer performs routing of the station addresses or station 
Ids found in the intranet header to determine if a relay transmission is required to reach the 
destination station. When a radio net is in the "RELAY" mode, those station addresses in 
the Intranet header are routed using the "connectivity" tables. Each station is examiner to 
determine the shortest relay path. See reference 1 for a full description of the Relay 
Protocol, the structure of the "connectivity" tables, and the self-organization protocols that 
support Layer 3B. 

The Transport layer on layer 4 provides a limited end-to-end accountability for 
messages which have been fragmented/segmented into multiple frames. 

The originating transport segments the message into frames, passes the frames to 

i 
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layer three and maintains the status of those frames. When the destination transport layer 
receives segmented frames it builds a list sorting the frames in their original order, deleting 
any duplicates. When the complete message is received or an accumulation timer expires, 
the destination transport sends an acknowledgment message to the originating transport 
layer for those frames that were received. The originating transport retransmits all frames 
missing from the acknowledgment message. When a message has been completely 
acknowledged the resources are released. When a message has been completely received it 
is reassembled and passed to the upper layer. 

The Transport layer controls the number of bytes that are placed in the information 
field of a frame. This byte count may be equal to or less than the size accepted by layer 2. 
This facility regulates the user's text size. Frames generated by other application interfaces 
may produce frames with information fields larger than those produced by the transport 
layer. 

A complete description of the Internet Header and the Transport layer fields will be 

given. 

The IMPROVED User Data Protocol requires operational parameters. These 
parameters are established by the operator/user and the MIS. Some parameters are 
maintained only by remote system and/or net managers. 

The operator interface consists of the establishment of station, net, link and system 
classmarks which support the lUDP. These data elements can also be maintained by a 
remote operator, ie Net Controller or MIS System or Sub-System manager. Remote or 
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local operations shall use the System Control (SYSCON) message protocol for all 
directives, alarms/notifications, and reports. The System Classmarks are established by the 
MIS System Manager prior to deployment and activation of the Network. The System 
Classmarks are NOT permitted to be modified during operations. In the event the MIS did 
not establish the System Classmarks prior to deployment, the Default System Classmarks 
values specified in this section shall be used. 

The System Classmarks are established by a central control facility. These 
classmarks defme those parameters which MUST be defined for the entire network/system. 
These parameters establish frame sizes, transport text size limits, valid address list, etc. 

Referring to Figure 5, there is shown a table which depicts the parameters that must 
be maintained on a network wide basis. As seen, the table of Figure 5 consists of a left 
hand column designated as system classmark parameter, a central column designated as 
default setting, and the end column indicating the purpose. Thus, for example, for the layer 
2 frame size depicted in figure 5 by row 75 one sees that the default setting is 256 octets 
and the purpose is to define the maximum size of the layer 2 in regard to the frame. 
Similarly, as one can ascertain there is given the transport text size, the transport window 
timer, the transport accumulation timer and so on. These parameters are as indicated 
maintained at a full network basis and are important to maintain reliable system operation. 

Referring to Figure 6, there is shown a table which depicts the Internet address 
masks which are used in conjunction with address class indicator. The masks values shown 
specify a 14 bit NIS (maximum size) and an eight (8) bit call sign. Implementers may 
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vary these masks however, these masks must be used by every station in the system 
network. Thus, as seen from figure 6, the masks consists of the following information: on 
the left is an address class, in the center is a mask value in HEX code and on the right 
column is a purpose. Thus looking at reference numeral 76 of figure 6 one can see that the 
address class of user class 1, uses a NIS mask which is 3 octets and is 3 FFFOO. The 
purpose is to isolate the NIS portion of the Internet address. Thus, each user class and 
equipment class including the Internet address class field are shown in Figure 6 together 
with their values and together with the indication of the purpose. It is noted that the 
Internet address is a 3 octet field. 

Referring to Figure 7, there is shown a table depicting the station (NODE) 
classmarks and parameters. The operator of the unit shall be permitted to enter all 
classmark data required by the station or NODE. As a minimum, this data shall include the 
parameters shown in the table of figure 7. Referring to figure 7, there is shown a table 
indicating the station class mark parameter on the left hand side column, the value range, 
the default range, and the purpose on the right hand column. For example, referring to row 
77, the station classmark parameters is the number of nets. There is no value range, the 
default value is one, and the purpose is multinet user, internet point indicates the number of 
classmark sets. Thus, as shown there is the appropriate value ranges for the data 
communications terminal, which is the DCE type, as well as for the data terminal 
equipment which is the DTE type. 

Referring to Figure 8, there is shown a table depicting use of half duplex radio 
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protocol whereby each station or NODE shall maintain dynamic parameters per net/link as 
indicated in the table shown in Figure 8. The table in Figure 8 as shown has a left hand 
column indicated station variable parameter with a value range, an initial value, and a right 
hand column showing the purpose. Thus, column 78, for example, indicates a station frame 
sequence number which has a value range of 0-3 F in HEX code, initial value of zero. The 
purpose of this is to identify every frame originated by a station to detect duplicate frames 
in the network. 

Referring to Figure 9A and 9B, there is shown a link/net classmarks. The operator 
is permitted to define the link/net classmarks as specified in figures 9A and 9B for each 
external interface, as for an example, for each link and/or net. This represents the 
minimum data required to operate the improved user data protocol. These classmarks can 
be combined in a single structure or they can be distributed between multiple structures. 
For example, referring to Figure 9A there is shown a left column designated link/net 
classmark parameter, then the value range, then the default value, then the purpose. Again 
referring to row 79 there is shown the net precedence. The value range is low or high, the 
default value is low. The purpose of this it is used to qualify the message precedence level, 
as for example, in routine high precedence levels versus routine low precedence levels. 
Referring, for example, to row 80 there is shown a DTE type where a value range is 
UDTHH or UDTHQ, which is user data terminal high priority with a defauh range as user 
data terminal HH and which specifies the DTE type assigned to the particular link. As one 
can understand these link net class marks are given for the relay net, relay update, the TDC, 
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the FEC, and so on. 

The half duplex radio protocol is based on HDLC LAPB. The concept of the frame, 
the link layer acknowledgments, and error detection have been adapted to facilitate the 
random access multi-point media of a combat radio net. The N(R) and N(S) have been 
replaced with a window size of four for a single radio broadcast (transmission). The radio 
link/net is assumed to be in the Asynchronous Balance Mode of the Information Transfer 
State, therefore link initialization procedures are not required. The options and classmarks 
enable this protocol to be implemented on a wide range radios with varying radio 
capabilities 

Features such as Forward Error Correction (FEC), and Time Dispersal Coding 
(TDC) are assumed to be functions of the modem; however, they can be implemented as 
the last step of the data interface in the physical layer. When present the FEC shall be 
transparent to the protocol described herein. 

The IMPROVED User Data Protocol is implemented using various physical 
interfaces. The physical layer betw^een Radios (HF & VHF) and terminals uses the X.21 
protocol using the Half Duplex Mode of operation. The Physical layer between terminals 
can be, X.21 (FDX Physical) using the lUDP Half Duplex point-to-point, or an 
Asynchronous (FDX Physical) also using the lUDP Half Duplex point-to-point. 

The data link layer is independent of the physical layer. The datal link processing is 
based on HDLC LAPB which is a widely used protocol. The data link protocol has the 
following restrictions/limitations: 
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1. Uses a 16 or 32 Bit Frame Check Sequence (FCS) 

2. Transmits the low-order bit first of each octet (Address Control & Information 

Fields) 

3. Transmits the Frame Check Sequence high-order bit first 

4. Does not use the N(R) or N(S) modulus 

5. Does use an I Frame window of four (4) in a single half duplex (radio) 
transmission 

6. Only uses the UI Frame (Unnumbered Information) of the U Frame Formats 

7. Uses a Special Address Field for radio nets. 

For the purposes of illustrations, all figures and tables depict the bit assignments in a 
binary format (hex). The bits are transmitted as specified above. 

The synchronization pattern consist of at least 4 HDLC FLAGS. This sequence is 
used for LINK Synchronization prior to the actual processmg of HDLC Frames in each half 
duplex (radio) transmission. 

The Data Link Layers perform that processing required by "I", "S", and "U" 
Frames. The Data link software discards all frames which are not addressed to its station. 
Link layer acknowledgments are processed and status alerts are returned/sent to the upper 
layer software. 

A radio (half duplex) transmission can contain muhiple frames. These multiple 
frames may be a combination of "S", "U", or "I" Frames. However a radio (half duplex) 
transmission may NOT contain more than four (4) "I" Frames. 
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Figures lOA to lOE there is shown the frame structures. The frame structures 
dictate all transfers of information, commands, and responses. These are accomplished 
utilizing frames which are bounded by Flags. The figures lOA to lOE show the frame 
structures for the half duplex operation. The frame fields are mandatory with the exception 
of the information field which can vary accordingly. Referring to Figure lOA, there is 
shown a frame format without an information field such as utilized by a half duplexed radio 
operation. As one can ascertain, a half duplex radio is a radio that can only receive or 
transmit and cannot receive and transmit simultaneously. In any event, the frame format is 
shown with the left column indicating the Flag format, the next column indicating the 
Intranet address field, the next column the control field, then the FCS field and then the 
Flag. 

In a similar maimer, referring to Figure lOB there is shown the frame format with an 
information field for half duplex radio operation. Figure IOC shows the firame format 
without an information field for half duplex PTP operation, PTP standing for point-to-point. 

Lastly, Figure lOD shows the frame format with the link layer address relay field 
which is used in relay nets. As one can ascertain all values are given in order to perform 
the frame format. The column designated FCS field stands for frame check sequence. 
Essentially, the sequence of every frame is checked by the FCS field which consists of two 
or four octets. It is noted that when a radio net is in a relay mode the address field for the 
relay protocol is placed over or positioned over the Intranet address field. This functionally 
» 
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expands the frames address field. 

Figure lOE depicts the general format of the frame when the relay link layer address 

field is used. 

The Flag is a unique eight-bit sequence of a zero, six ones, and a zero (01111110). 
A Flag is transmitted at the beginning and at the end of each frame. Frames received 
without beginning and ending flags are ignored. 

At the transmitting station, the flag that ends a frame cannot be the opening flag of 
the next frame; that is at least two flags separate successive frames. The receiving station, 
however, is capable of accepting frames separated by only one flag. This feature facilitates 
the ability to discern a valid frame on a link which has experienced data corruption due to a 
link error. 

The frame's address field contains an Intranet Address field or in the case of "Relay" 
nets, a Link Layer Relay Address field and the Intranet Address field as shown in Fig. 11. 
This specification does not define the Link Relay Address field. For Point-to-Point links 
the address field consists of a single octet of the Full Duplex Point-to-Point protocol, as 

will be explamed. 

Each link is classmarked specifying the type of interface: 

1. Radio Net "All Informed" 

2. Radio Net "Relay" 

3. Point-to-Point access circuit 

This classmark data defines the type of validation and processing required for the 
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address field. 

The Address field is variable in size and consists of three (3) to 18 octets. The 
subfields consists of a Type/Sequence field, the originators station address and a list of up 
to 16 destination addresses. Each address octet contains seven bits of station address 
followed by a continuation bit* When the continuation bit is reset (zero), it indicates that 
another address octet follows. The LASR destination addressee shall have it's continuation 
bit set (one). 

The coding of the Intranet Address Field shown in Fig. 12. 

The Frame Type and Sequence number are used in conjunction with the originator's 
station address to identify the frame and report the station's mode, Ready/Not Ready. The 
Type field is set to the IMPROVED User Data Protocol "User Frame" value which 
indicates the mode, and the station's sequence number is assigned just prior to the initial 
transmission of the frame. This sequence number is NOT changed on retransmission of the 
frame. This sequence number is NOT changed on retransmission of the frame, however the 
station mode may change. 

Each station shall keep a sequence number for originating frames. In addition each 
station shall keep a record of frames processed in a process log. The number of entries 
shall be specified in the Station Classmarks. If a received frame is valid and requires an 
acknowledgment, the frame is acknowledged. The process log is examined for the 
sequence number and the station address of the frame just received. If the frame is found, 
it is discarded, if NOT found, it is placed in the process log. This procedure prevents 
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duplicate frames from being transmitted through the Internet. The typical reason for a 
frame being retransmitted is that the originating station did NOT receive the 
acknowledgment correctly. The Figure 13 depicts the format of this subfield. 
The Frame Type Codes are as follows: 

00 = User Frame and Station Ready 

01 = User Frame and Station Not Ready 

10 = Reserved 

1 1 = Reserved 

The Frame Type indicates the station's mode, Ready or Not Ready. This data is a 
duplication of information when the frame is a Receiver Ready or a Receiver Not Ready S 
Frame; however, it eliminates the need for periodic S Frames by indicating the station's 
mode with every I Frame, or U Frame transmission. 

Each Address octet for the Half Duplex Protocols contain two fields; the station 
address field and the continuation bit or LAST address indicator. The Address field is 
variable and each address octet indicates if additional address octets follow. The station 
address or station number is a seven (7) bit field. Two special addresses are reserved for 
the IMPROVED User Data Protocol, the Null address and the Global address. The NULL 
address has a station address of zero and the Global address has a station number of 127 
(all bits set). The Global address MUST be the last address in the Intranet address field 
(LAST in set). The global address can be used in combination with specific addresses; 
however, it MUST be the last addressee. The NULL address is reserved and User's shall 
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not assign zero as a station address. 

Figure 14 sliows the format of an Address Octet. 

For half duplex operation the control field consists of one octet. The control field 
specifies the fi-ame type and contains an I Frame sequence number bit map. The coding of 
the control field for the S Frame and the I Frame will be described later. 

The information field follows the control field in I Frames. The information field 
contains an integral number of octets, up to a maximum as specified in the configuration 
parameters. Any bits added to the information field to make it an integral number of octets 
Ji are set to zero. 

All frames include a Frame Check Sequence (FCS) (Figs. lOA-lOE). The FCS for 
£ the half duplex protocol shall be a 16 or 32 bit remainder of a modulo 2 polynomial 
' division process on the contents of the address, control and information fields prior to the 
Li zero bit insertion. The FCS size to defined in the Link/Net Classmarks. 
yi A station may terminate a frame at any time in the process of transmission by the 

'ir;;; i:^ 

transmission of an abort sequence. An abort sequence consists of seven (7) to 15 
contiguous one bits. 

To provide complete transparency for transmitted data a zero bit insertion 
mechanism is used to prevent a flag sequence from occurring in the frame. A zero is 
inserted by the transmitting station following five (5) contiguous one bits in the data stream. 
This includes the last five bits of the FCS. 

Receive data is examined to remove these inserted zero bits. When five contiguous 
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one bits are detected, the sixth bit is examined. If the sixth bit is a zero, it is deleted; if the 
sixth bit is one, the seventh bit is examined. If the seventh bit is a zero, a Flag is detected. 
If the seventh bit is one, then an abort sequence is detected. 

An invalid frame is one which is not bounded by a beginning and ending flag, or 
one which is too short, or one which is too long. Frames which have an invalid Frame 
Type, an invalid address field, an invalid control field or a FCS error are discarded as an 
invalid frame. 

A frame is too short when there are less than four octets between flags for the 16 bit 
FCS Point-to-Point or six octets between flags for the 32 bit FCS. A frame is too long 
when the number of octets exceeds the SPECIFIED maximum size, A frame which has 
terminated by an abort sequence is invalid. Invalid frames are ignored and discarded upon 
detection of the error. 

Half duplex LAPB system parameters apply to both the DCE and the DTE. No 
variation exists between the two stations. The values of these parameters are either fixed as 
indicated or as specified in the Station or Link/Net Classmarks (Fig. 9A, 9B). The DCE 
and DTE LAPB system parameters are as follows: 

HDX Tl TIMER 

The HDX Tl timer is the maximum time a station waits for an acknowledgment of a 
frame transmitted before the frame is retransmitted. The value of Tl is in seconds as 
specified in the Link/Net Classmarks. Each frame transmitted is assigned to Tl timer. 
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When the Tl timer expires for an I Frame, that I Frame is retransmitted in the next 
transmission opportunity, assuming the maximum retransmission count has not been 
reached. Also the HDX Tl timers for I Frames are halted in the event the receive station 
replies with an RNR S Frame indicating a busy condition. The I Frames for that station are 
removed from the transmit queue until the station clears its busy condition and resumes 
traffic with a RR S Frame. 

T2 TIMER 

The T2 timer is the amount of time a station should wait before an acknowledging S 
Frame is initiated for received I Frame(s). For the IMPROVED User Data Protocol this 
value is 200 milliseconds (RADIO TURNAROUND TIME), Pending acknowledging S 
Frames are transmitted at the next opportunity. 

HDX N2 MAXIMUM TRANSMISSION ATTEMPTS 

The HDX N2 parameter indicates the maximum number of attempts to complete the 
successful transmission of an I Frame. The value of HDX N2 is the maximum retransmit 
value as specified in the Station Classmarks (Fig. 9) plus one (1) for the original 
transmission. 

Nl MAXIMUM NUMBER OF BITS IN AN I FRAME 

Nl is an adjustable parameter based on the system classmarks. The default value is 
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2,048 or 256 octets. This parameter must be padded to align on an octet boundary. 



HDX K MAXIMUM NUMBER OF OUTSTANDING I FRAMES 

The value of K indicates the maximum number of sequentially numbered I Frames 
that a station may have outstanding (Not acknowledged) at any given time. For the 
IMPROVED User Data Protocol this value is four (4). 

ORIGINATING STATION FRAME SEQUENCE NUMBER 

The value of the station's sequence number is a binary (6 Bit) value starting at a 
value of zero, and being incremented by one for every frame that originates from the 
station. This value is not incremented for retransmitted frames, 

INFORMATION TRANSFER STATE 

Stations shall enter the Information Transfer State (ITS) without any special 
initialization procedures. 

The Information Transfer State allows the exchange of I-frames, S-frames, and U- 

frames. 

I-FRAME PROCESSING 

The I-frame is either a new message frame from the local user, or a retransmission 
of an I-frame which was not acknowledged within the Timeout Period (TP). I-frames are 
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retransmitted up to HDX N2 times, where HDX N2 is as specified by the station 
classmarks. 

Referring to Figs. 15A and B there is shown I-Frame formats. Message data is 
exchanged using "I" Frames. The IMPROVED User Data Protocol specifies the format of 
"I" Frames as shown in Fig. 15A and 15B. 

A description of the Address Field is presented later on. 

Fig 16A shows the CONTROL FIELD FORMAT and Fig. 16B shows the 
INFORMATION FIELD FORMAT. 

The numbers in Fig. 16A and 16B reflect the Default Values as specified in the 
System Classmarks. The Transport Layer uses the text size as specified in the System 
Classmarks. The half duplex link layer will accept frame sizes as specified in the System 
Classmarks. The sizes quoted for the Internet Header (FIG. 16B) are 13 for the minimum 
size header and 105 for the maximum size header. The minimum size header contains a 
single Basic Address and the maximum size header contains 16 Extended addressses. 

Transmitted I-frames are acknowledged by RR response S-FRAMES from the 
receiving stations, except for the following cases: 
L The Control field of the I-frame specifies no acknowledgement. 

2. The user has set the Response Mode in the station classmarks to disable 
acknowledgment. 

3. The receiving station is a global addressee only. 

4. The receiving station's unique link address (Station number/identifier) is not in the 
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Intranet Address field. 
5. The receiving station's unique link address is not in the Link Relay Header. 

S-frames are used to convey link supervisory data including acknowlegement of an 
I-frame and whether or not a station is ready to receive. The S-frame format is as shown in 
Figs. 17A and 17B. 

The Intranet Address Field is limited to two addressee octets, the first octet is the 
originating station (of the S Frame), and the second is the destination station of the S 
Frame. The destination address may be the global station value when transmitting either 
the RR or RNR Command Frame. The Frame Type also indicates the station mode 
(Ready/Not Ready). 

Fig. 18 depicts the format of the control field for HALF DUPLEX (DTE) RADIO 
PROTOCOL. 

In Fig. 18, II is used to acknowledge a Single Frame Transmissions II not set in the 
received "I" frame. Also any combination of bits may be set, acknowledging multiple "I" 
frames (up to 4). 

"05" HEX = RNR Command - Does NOT acknowledge "I" frames. 
"01" HEX = RR Command - Does NOT acknowledge "I" frames. 

RECEIVE NOT READY PROCEDURE 

A station shall generate and transmit an RNR Command if its Response Mode 
station classamark is enabled and it receives an I-frame which it cannot accept because its 
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receive buffers are full. A station shall also generate an RNR command when directed by 
the user interface. The RNR S-FRAME does NOT acknowledge any I-FRAME. The 
Frame Type Field is also set to the Not Ready value. 

Upon receipt of an RNR frame from the interfacing station, a station shall 
temporarily inhibit transmission of I-Frames to that station and shall transfer a Degraded 
Performance Signal to the user interface. Normal transmissions of I-Frames to that station 
shall resume upon receipt of an RR command from the station, when it receives an I Frame 
with the Frame Type field set to Ready, or when commanded by the local user/operator. 

To implement a receive ready procedure, a station generates and transmits an RR 
frame if its Response Mode station classmark is enabled and one of the following 
conditions exist: 

1. The station is no longer busy and had previously sent an RNR command. 

2. The station has accepted an I-frame from a transmitting station which 
requires acknowledgement. 

3. As directed by the user/operator. 

The control field of the RR frame indicates RR command and RR response. The 
RR response is generated and transmitted by a station to acknowledge the acceptance of an 
I-frame, and is addressed to the I-frame originator. 

The RR command is generated and transmitted by a station to indicate the end of the 
busy/buffer full condition. The Frame Type field is also set to the Ready value when a 
busy condition clears. The RR command frame is addressed to the global address (ALL 
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ONES). The RR Command S-FRAME does NOT acknowledge any I-FRAMES. 

For U-FRAME Processing the half duplex protocol only uses the UI Frame. This 
frame has an information field. The UI Frame is not acknowledged in the half duplex 
protocol. Within the Frame priority, the UI Frame is transmitted before any pendng S or I 
Frames. The UI Frame uses the appropriate address field for the half duplex mode. 
Received UI frames are passed to an intermediate Layer for processing. 

The UI Frame has the format shown in Fig. 19. 

A description of the Address Field will be presented. The Address field for Point- 
|]To-Point interfaces shall also be described. 

The UI Frame Control field is coded as follows: 

UI FRAME CONTROL FIELD 
1 OCTET 

0 0 0 0 0 0 11 

The Information field is User defmed and is limited to the frame size as specified in 
;i the System Classmarks. The FCS shall be either a 16 or 32 bit field as defined in the 

Link/Net Classmarks. 

The multiple station net access and data net sensing ensures orderly and 
nonconflicting transmissions. There are four basic subfunctfons that are implemented to 
ensure coordinated net access by its stations: 

NET BUSY SENSING 

The presence of multiple stations on a single random access communications net 
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requires data Net Busy Sensing and the use of the net access control to reduce the 
possibility of data collisions on the net. 

The combined Data and Voice Nets require cooperation between the DTE and the 
DCE (radio)* The Data itself is based on precedence and therefore is used in Net Access 
Delay calculations. 

The DCE (radio) indicates the presence of receive data with the signal on the 
X21 interface. The "I" ON represents: 

1. Data being received 

2. Voice being received 

3. Radio Busy (not available) 

4. Voice being transmitted 

Message transmissions resume after the data Net Busy Sensing indicator (the X.21 
"I") is reset (OFF) for the following conditions: 

1 . loss of RF signal (voice or data) 

2. Voice transmission complete 

3. Radio is no longer busy 

RESPONSE HOLD DELAY (RHD) 

There are two modes of Response Hold Delay: 

1. "Scheduled" Acknowledgement 

2. "CSMA" Acknowledgement 
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The Scheduled Acknowledgement is where the layer two schedules the 
acknowledgement based on ly on the RHD, The CSMA Acknowledgement is where layer 
two sends the acknowledgement (transmit request) as soon as it can and the radio Carrier 
Sense Multiple Access (CSMA) resolves the net access problem. In the "CSMA" mode the 
RHD is set to zero. In the "Scheduled" mode the RHD is computed based on the address 
position. This calculation is described in the paragraphs below. 

The RHD is the time each receiving station delays before responding with an RR, or 
RNR S-FRAME upon receiving an I-FRAME. The number of RHD periods used is 
determined by the position of the receiving station's address in the I-FRAME Address Field. 
One RHD period is calculated by the following formula; 
RHDo = A + F + D + T 
Where: A - RADIO SYNC TIME 

F = FRAME TRANSMIT TIME (S-FRAME) 
D = FORWARD ERROR CORRECTION (RADIO) DELAY 
T - TRANSFER TIME (DCE to DTE) 
The individual addressee's Response Hold Delay (RHDi) is calculated by: 
RHDi = (i4)RHDo + P 

Where: (1 <= i <= 16) = the individual station's position in the Intranet 

Address field 

OR 

Where: (1 <= i <= 64) = the individual station's position in the Intranet 
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Address field of the last frame in a multi-frame transmission 

AND 

P = Processing/safe store time (1st addressee only) 

TIMEOUT PERIOD (TP) 

The TP is defined as the time required by the transmitting station to: 

1) provide a window of time in which to receive the anticipated response frame(s), 

and 

2) to establish a period of time before it will schedule the Net Access Delay (NAD). 
The TP is required by the receiving station to establish a period of time before it 

will schedule the NAD. The TP is for all stations regardless if they are an addressee or 
not. 

Upon completion of a message transmission, the transmitting station will start the TP 
timer. If all expected responses are NOT received before the TP, the message is queued 
(LIFO by precedence) for retransmission with the previsouly acknowledged addresses 
deleted from the new Intranet Address field. The message is retransmitted when its 
precedence is at the top of the queue. 

In the "Scheduled" Acknowledgement mode the TP is calculated by all stations on 
the net as follows: 
TP = j(RHDo) + P 

Where j = The total number of addressees in ALL the frames in the 
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transmission that require acknowledgement 
In the "CSMA" Acknowledgement mode the TP is calculated by all stations receiving the 
message as follows: 
TP = HDX Tl 

Where HDX Tl is defined in the Link/Net Classmarks 

NET ACCESS DELAY (NAD) 

NAD is defined as the time a station must wait after detecting a net NOT busy 
before attempting to access the net. This procedure is dependent on the acknowledgement 
mode. The "CSMA" Acknowledgement mode is where the protocol relies on the radio 
CSMA algorithm to resolve contention in a given priority category. For the "Scheduled" 
Acknowledgement mode, the layer two resolves the contention. 

The message precedence is used in this calculation to ensure that the highest 
precedence message occupies the net. 

If an I-frame is received satisfactorily, each receiving station initiates a TP timer to 

allow the addressees to respond. 

If an I-frame is not received satisfactorily, the receiving station waits for the 
expiration of the message length time before initiating the NAD. The message length time 
is calculated as: 

TP = 16 X RHDo (Assume 16 addresses) for the Scheduled mode 
TP = 1.5 seconds for the CSMA Mode 
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After the TP timer expires, each station calculates its individual NAD. The NAD 

shall be calculated by the following formula for the scheduled mode: 

AND = (C + (10ms * R) + (50ms * p)) 

Where: C = Channel Access Time 

p = Precedence of I-FRAME on the top of the queue 
(0 = the Highest & 3 = the Lowest) 

R = Random integer from 0 to 7 
The NAD shall be calculated by the following formula for the CSMA mode: 
NAD = (50ms * p) 

Where: p = Precedence of I-FRAME on the top of the queue 
After NAD expires the Net Busy is tested. 

1. If the Net is NOT BUSY, the Highest precedence I-FRAME is transmitted. 

2. If the Net is BUSY, the receive must process the data after the X.21 "I" lead 
is OFF. 

3. If there is no data, voice is assumed and NAD is recomputed. 

4. When data is present TP is calculated. 

The full duplex protocol and procedures is used on synchronous communications 

links between two stations. 

The Full Duplex IMPROVED User Data Protocol is based on the X.25 
recommendations as specified in the CCITT RED BOOK. This protocol uses the Link 
Access Procedures Balanced (LAPB). The physical interface for this protocol is X.21 
leased circuit service - point-to-point and packet-switched service. The class of procedure 
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is balanced asynchronous, using only the basic mode of operation. 

The IMPROVED User Data Protocol is implemented using various physical 
interfaces. The X.21 interface is one of these interfaces. 

The data link layer is independent of the physical layer. The data link layer requires 
synchronous full duplex communications links. The data link processing is based on 
HDLC LAPB as described in recommendation X.25. The data link protocol has the 
following restrictions/limitations: 

1. uses the basic mode only (Modulus 8); 

2. does not use the SREJ S-Frame; 

3. uses a 16 or 32 Bit Frame Check Sequence (FCS); 

4. transmits the low-order bit first of each octet (Address Control & Information 
Fields); 

5. transmits the Frame Check Sequence high-order bit first; 

For the purposes of illustration, all figures and tables depict the bit assignments in a 
'' binary format (hex). The bits are transmitted as specified above. 

FRAME STRUCTURES 

All transfers of information, commands, and responses is accomplished utilizing 
frames bounded by flags. The following tables shown in Fig. 20A and 20B depict the 
frame structure for the basic (Modulo 8) operation. All frame fields are mandatory, with 
the exception of the information field. 
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FLAG SEQUENCE 

The Flag is unique eight-bit sequence of a zero, six ones, and a zero (01111110). A 
Flag is transmitted at the beginning and at the end of each frame. When the link is 
"active", flags are transmitted between frames as interframe time fill and whenever the 
station is not transmitting a frame or an abort sequence. Frames received without beginning 
and ending flags are ignored. 

At the transmitting station, the flag that ends a frame is not the opening flag of the 
next frame; that is at least two flags separate successive frames. The receiving station, 
however, is capable of accepting frames separated by only one flag. This feature facilitates 
the ability to discern a valid frame on a link which has experienced data corruption due to a 
link error. 

ADDRESS FIELD 

The Address field consists of one octet. The coding of the Address Field is as 
follows; 

Single link Operation Command 00000011 

Response 00000001 
Each station shall discard frames received with an address other than Command or 
Response. 

CONTROL FIELD 
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For modulo 8 (basic) operation the control field consists of one octet. 

The control field contains a command or a response, and sequence numbers where 
applicable. Three types of control field formats are used: numbered information transfers (I 
format), supervisory functions (S format) and unnumbered control functions (U format). 
The control field formats for basic operation are presented in the table shown in Figure 21. 

RECEIVE READY (RR) FRAME 

The receive ready (RR) supervisory frame is used to: 

1 . indicate that the station is ready to receive an I Frame 

2. acknowledge previously received I Frames numbered up to and 
including N(R)-1 

3. clear a previously busy condition. 

The RR frame transmitted with the P bit set (command) is used by a station to ask 
for the status of receiving station. The response (RR/RNR) is returned with the final bit 
set. 

RECEIVE NOT READY (RNR) FRAME 

The receive not ready (RNR) supervisory frame is used to indicate a busy condition 
by the transmitter. The RNR acknowledges previous I Frames up to and including N(R)-1. 
The RNR frame transmitted with the P bit set (command) may be used by a station to ask 
for the status of receiving station. The response (RR/RNR) would be returned with the 
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final bit set. When a station is in the busy condition, and an I Frame is received, a RNR 
frame is transmitted to reinforce the busy condition. The N(R) does not acknowledge the I 
frame received during the busy condition, 

REJECT (REJ) FRAME 

The reject (REJ) supervisory frame is used by a station to request transmission of I 
frames starting with the frame number N(R). I frames numbered N(R)-1 and below are 
acknowledged. Additional I frames pending initial transmission may be transmitted 
following the retransmitted I frames. Only one REJ exception condition for a given 
direction may be established at any time. The REJ exception condition is cleared upon 
receipt of an I frame with a N(S) equal to the N(R) of the REJ frame. The REJ may be 
used to clear a busy condition that was reported earlier by a RNR. A REJ with the P bit 
set also requests the status of the receiving station. 

The following table of Fig. 22 depicts the general U Frame format and those specific 
formats which are used by the IMPROVED User Data Protocol. 

It is indicated in conjunction with Fig. 22, unnumbered frames (commands and 
response) are used to extend the number of link supervisory functions. Unnumbered frames 
do not directly modify the send or receive variables at either the sending or receiving 
stations. Unnumbered frames can alter the link mode and therefore reset the send and 
receive variables. A link has on unnumbered frame outstanding in each direction. 
Unnumbered frames require an acknowledgment is performed by the receiving station 
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sending an Unnumbered Acknowledgment (UA) frame. The transmission of the UA frame 
is an indication that the receiving station has received, accepted, and implemented the 
command. The recipient of the UA frame can implement the command at it's station when 
applicable. The following are descriptions of the Unnumbered Frames exchanged by the 
IMPROVED User Data Protocol. References to the link state and modes by the mode 
setting frames are discussed in detail later. 

UNNUMBERED INFORMATION (UI) FRAME 

UI frames are used to contain information exchanges for protocol layers higher than 
the link level A UI frame's contents are analyzed at the higher layers, but a UI frame is 
acknowledged with a UA response frame at the link layer. UI frames are accepted in a 
busy condition but not in a disconnected state. 

SET ASYNCHRONOUS BALANCE MODE (SABM) FRAME 

The SABM command is used to place both stations in an asynchronous balanced 
mode (ABM) Information Transfer State where all command/response control fields are one 
octet in length. When an SABM frame is acknowledged or when an acknowledge is 
received for an SABM sent, the station resets both the send and receive variables and clears 
all exception conditions. 

Previously transmitted I frames that are unacknowledged when this command is 
implemented remain unacknowledged. It will be the higher layer protocols responsibility 
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for the recovery/retransmission of those I frames. 

The SABM causes the transition from the Link Initialization Mode (LIM) of the 
Initialization State (IS) to the Asynchronous Balance Mode (ABM) of the Information 
Transfer State (ITS). 

DISCONNECT COMMAND (DISC) FRAME 

The DISC command is used to terminate the current mode. The command informs 
the receiving station that operations are being suspended or terminated. The receiving 
station acknowledges the DISC command by the transmission of an UA frame. Previously 
transmitted I frames that are acknowledged remain unacknowledged. It is the responsibility 
of the higher layer protocol to take recovery actions. When a station transmits a DISC 
command frame, it does not accept additional I frames by the use of a RNR S frame. 

SET INITIALIZATION MODE (SIM) FRAME 

The SIM command is used to cause the receiving station to initiate procedure for the 
initialization of the link layer functions. The SIM command causes the transition from the 
Asynchronous Disconnect Mode (ADM) of the Logical Disconnect State (LDS) to the Link 
Initialization Mode (LIM) of the Initialization State (IS). 

UNNUMBERED ACKNOWLEDGMENT (UA) FRAME 

The UA response is used by a station to acknowledge the receipt and acceptance of 
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Unnumbered frames. Received made setting commands are not actuated until the UA 
response is transmitted/received. 

DISCONNECT MODE (DM) FRAME 

The DM respones is used to report a status where the station is in the Logical 
Disconnect State. 

FRAME REJECT (FRMR) FRAME 

The FRMR response is used by a station to report an error condition not recoverable 
by the retransmission of the identical frame. 

The IMPROVED User Data Protocol only uses the FRMR to report an invalid N(R). 
The recommended action by the recipient of an FRMR for an invalid N(R) is to send an 
SABM to clear the send and receive variables. A station accepts a FRMR frame which 
indicates other detected errors, and the recommended action is to forward the information to 
the User/Operator. These other error conditions causes the frame to be discarded by the 
recipient. The sender retrys until all retransmissions have failed and then initiates 
disconnect procedures by the transmission of the DISC command. 

The FRMR U Frame contains an information Field and the coding is shown in 
Figure 23. 

As stated above the lUDP discards and ignores frames that contain the errors as 
specified by the reason bits W, X, & Y. It is assumed that the sending station will 
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retransmit the frame in question and the receiving station will receive it correctly. If the 
frame is not received correctly the sending station v^U initiate disconnect procedures and 
both stations will enter the ETM of LDS and test their respective hardware. 

INFORMATION FIELD 

The information field follows the control field in I Frames, and UI Frames. The 
information field contams an integral number of octets, up to a maximum as specified in 
the configuration parameters. Any bits added to the information field to make it an integral 
■ number of octets shall be set to zero. 

The structure of the I Frame Information field is the same as in the half duplex 
= protocol. The Information field structure will be described. 

1 FRAME CHECK SEQUENCE 

All frames include a Frame Check Sequence (FCS). The FCS for the fiiU duplex 
' protocol is a 16 or 32 bit remainder of a modulo 2 polynomial division process on the 
contents of the address, control and information fields prior to the zero bit insertion. The 
FCS size is defined in the Link/Net Classmarks. 

ABORT SEQUENCE 

A station may terminate a frame at any time in the process of transmission by the 
transmission of an abort sequence. An abort sequence consists of seven (7) to 15 
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contiguous one bits. 

ZERO BIT INSERTION/DELETION 

To provide complete transparency for transmitted data a zero bit insertion 
mechanism is used to prevent a flag sequence from occurring in the frame. A zero is 
inserted by the transmitting station following five (5) contiguous one bits in the data stream. 
This includes the last five bits of the PCS. 

Receive data is examined to remove these inserted zero bits. When five contiguous 
lone bits are detected, the sixth bit is examined. If the sixth bit is a zero, it is deleted; if the 
3 sixth bit is a one, the seventh bit is examined. If the seventh bit is a zero, a Flag is 
i detected. If the seventh bit is a one, then an abort sequence is detected. 

] INVALID FRAME 

An invalid frame is one which is not bounded by a beginning and ending flag, or 
^ one which is too short, or one which is too long. Frames which have an invalid address 
field or a FCS error are discarded as invalid frames. 

A frame is too short when there are less than four octets between flags. A frame is 
too long when the number of octets exceeds the SPECIFIED maximum size. A frame 
which has terminated by an abort sequence is invalid. Invalid frames are ignored and 
discarded upon detection of the error. 
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LOGICAL STATES, MODES, AND CONDITIONS 

All stations shall be in one of three states: logical disconnect, initialization, or 
information transfer. Within each are modes which specify response opportuniiies and a 
logical data link configuration. Figure 24 shows the logical states and modes, and the 
transitions between stations. 

As shown in Figure 24, there exists three distinct states for the equipment which are 
dictated by the protocol. Each station as any DTE or DCE is in one of the three states 
which is shown in Figure 24 is a logical disconnect state shown on the left hand side, an 
initialization state shown in the center, and an information transfer state. As seen by the 
legend an AIM stands for automatic initialization mode, EIM is equipment initialization 
mode and so on. Therefore, one can determine based on events exactly what will occur by 
reference to figure 24. Thus as depicted in Figure 24, equipment can be transferring 
information or can be transferring flags as attempting to obtain synchronization, can be in a 
local test mode or can experience a protocol or hardware failure which would initiate a 
time-out 

Referring to Figure 25, there is shown a table which shows the station responses to 
received frames in the three link states. For example, in the row designated as I Frame, 
one state can be the asynchronous disconnect mode where the equipment sends a disconnect 
mode signal (DM) or an asynchronous disconnect mode signal. In the link initialization 
mode which is the LIM of the initial state the equipment sends nothing or sends a link 
initialization mode signal. In the ABM state, which is the asynchronous balance mode, one 
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can send no response or a asynchronous balance mode signal 

LOGICAL DISCONNECT STATE (LDS) 

The LDS is provided to prevent a station from appearing on the link in a fully 
operational sense during unusual situations or during exception conditions. No information 
or supervisory frames are transmitted or accepted while a station is in LDS. When a station 
is in the Asynchronous Disconnect Mode (ADM) of LDS, only Unnumbered frames may be 
transmitted or responded to. Each LDS mode is described in the following paragraphs. 

^: EQUIPMENT INITIALIZATION MODE (EIM) 

A station enters the equipment initialization mode when a link is activated by the 
Li operator or when auto initialization (Optional Mode) is active following a loss of 
;j synchronization or a protocol disconnect/failure. During the time no frame activity is sent 
to or received from the link. The station transmits flag characters and monitors the link for 
receipt of flag characters. Link synchronization is established upon receipt of flag 
characters, and the station enters the Asynchronous Disconnect Mode (ADM). The station 
shall remain in EIM until synchronization is achieved (no time limit) or exit to Equipment 
Test Mode on operator command or on detecting a hardware fault. 

ASYNCHRONOUS DISCONNECT MODE (ADM) 

The station enters ADM from EIM upon achieving link synchronization (transmitting 
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and receiving flags) or from the Asynchronous Balanced Mode of the Information Transfer 
State when a DM Response Frame is received. While an ADM, the station continues to 
transmit flags sequences to maintain synchronization and a SIM Command Frame is 
transmitted on the link. The station exits ADM: 

1. to the equipment test mode upon loss of synchronization, operator command, 
or upon five transmission of the SIM without acknowledgment followed by 
acceptance of a DISC Command Frame, or five transmissions of the DISC 
frame without an acknowledgment, 

2. to the link initialization mode of the initialization state upon receipt of an 
acknowledgment for the transmitted SIM, or upon transmitting an 
acknowledgment for a received SIM Frame. 

3. to the equipment test mode upon transmitting an acknowledgment for a 
received DISC Frame. 

The following specify the procedure which are followed to effect recovery after 
detection of exception conditions. 

SIM received after SIM sent 

If a station receives a SIM after having sent a SIM, the station acknowledges the 
received SIM and enters the Link Initialization Mode of the Initialization State. 
However the sent SIM condition (U Frame outstanding) must be cleared by the 
receipt of an acknowledgment (UA Frame) or a timeout (basic mode, 2 seconds) 
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before another U frame an be sent. 

SIM not Acknowledged 

If a SIM times out, it shall be retransmitted (up to 4 retransmissions). A received 
SIM is acknowledged and the station enters the LIM of IS. While in LIM of IS, the 
outstanding SIM prevents another U Frame from being transmitted. This condition 
is cleared when an acknowledgment is received. Due to synchronization timing, a 
station may miss a SIM Frame. When a SIM timeout occurs after the transition to 
LIM of IS, the SIM condition is considered resolved and the pending U Frame is 
transmitted. 

AUTOMATIC INITIALIZATION MODE (AIM) 

The AIM is an optional mode. Its purpose is to relieve the operator from the task of 
initializing the link after a disconnect (assuming local equipment test pass). 

The AIM procedures are entered from ETM and simulate the operator command to 
initialize the link. 

EQUIPMENT TEST MODE (ETM) 
Stations enter ETM when: 

1 , Equipment validation tests fail or the operator stops the synchronization 

process while in EIM, or the operator halts the link while in the Information 
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Transfer State. 



2. 



Synchronization, or protocol failure occurs in LDS. IS, or ITS. 



3. 



A DISC Frame was acknowledged. 



4. 



After 15 seconds without receiving any valid frame 



A protocol failure is defined as exceeding the maximum number of retransmission of 



a frame without receiving an acknowledgment. The ETM executes those diagnostic tests 
requu-ed to determine that the hardware associated with the link is working correctly. No 
frames are transmitted or accepted while in the ETM. The station shall remain in ETM 
until: 

1 . Internal tests fail, and the station enters the Equipment Failure Mode (EFM) 

2. The operator request the link to be initialized, and the station enters the EIM 

3. A successful test sequence has completed an the AIM option is enabled, the 



EQUIPMENT FAILURE MODE (EFM) 

Stations enter the EFM upon failure of the internal equipment tests while in ETM. 
In EFM, stations shall neither transmit or accept any data on the link. Stations exit EFM to 
ETM upon direction from the operator after correcting/replacing the failed equipment. 

INITIALIZATION STATE 

The Initialization State only contains one (1) mode, the Link Initialization Mode 



station enters the AIM 
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(LIM). 



LINK INITIALIZATION MODE (LIM) 

The LIM is entered when a station acknowledges a SIM or receives an 
5 acknowledgment for a transmitted SIM. 

Only U Frames may be exchanged during the initialization state. A SIM timeout 
clears the SIM condition in the LIM. 

The station exchanges SABM frames with the distant station. When either a station 
Q sends an acknowledgment for a received SABM or received an acknowledgment for a 
10 transmitted SABM the station transitions to the Information State (ITS). The SABM 
specifies the basic mode (modulus 8). 

=1 INFORMATION TRANSFER STATE (ITS) 

All frame types are permitted in the ITS. The ITS encompasses one mode, the 
15 ™l Asynchronous Balance Mode (ABM). 

ASYNCHRONOUS BALANCE MODE (ABM) 

There are conditions withm ABM used to facilitate the control of traffic flow. The 
ABM of ITS is where I frames are exchanged between the two stations. 
20 The ABM of ITS is entered from LIM of IS when a UA is received for a 

transmitted SABM or when a UA is transmitted for a received SABM. While in ABM, 
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each station is capable of transmitting and receiving I, S, and U frames, subject to the 
constraints of the station condition within ABM as defined in the following paragraphs. 
A station exits ABM and goes to ETM or ADM as follows: 

1. To ETM when a frame is repeated five (5) times without acknowledgment 
followed by the acknowledgment of a transmitted DISC or after five (5) 
transmissions of the DISC without an acknowledgment. 

2. To ETM when a DISC is received and acknowledged, or when NO VALID 
frame is received for 15 seconds. 

3. To ADM when a DM is received. 

The following are descriptions of the various conditions which can exists in ITS. 

NORMAL CONDITIONS 

The normal condition of ABM within ITS has the following characteristics: 

1. Both stations are in the receive ready condition, both exchanging RR Frames. 

2. There exists no link exceptions, when neither station is retransmitting I 
Frames or waiting for retransmitted I Frames as a result of one or both 
stations transmitting/receiving a REJ Frame. 

BUSY CONDITION 

A busy condition occurs when a station temporarily cannot receive I Frames due to 
internal constraints, such as buffer limitations. The Busy Condition is reported by the 
U-ansmission of a RNR Frame with the N(R) of the next expected I Frame. All frames 
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equal to or less than N(R)-1 are acknowledged. I Frames received by a station which has 
transmitted a RNR are responded to by another RNR, and the received I Frames are 
ignored. When a RNR is received, the station ceases transmitting I frames. The station 
does not resume the transmission of I Frames until the Busy condition has been cleared. 
The Busy Condition is normally cleared by the receipt of a RR Frame. Other frames are 
clear a busy condition are: 

REJ Frame 

SABM Frame 



EXCEPTION CONDITIONS 
N(S) Sequence Error 

An N(S) sequence exception is established in the receiving station when an I Frame, 
otherwise error free, contains an N(S) sequence number which is not equal to the expected 
Receive variable. The receiving station ignores the I Frame, and responds with a REJ 
Frame indicating the next expected sequence number specified by the N(R). Previous I 
Frames v^th sequence numbers equal to or less than N(R)-1 are acknowledged. 

The station which received a REJ Frame shall retransmit all outstanding I Frames 
starting with the sequence number as specified by the N(R) in the REJ Frame. New I 
Frames shall be held until the retransmission has completed. 
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N(R) Sequence Error 

When a frame is received with an N(R) greater than the next send sequence number 
a non-recoverable exception has been established. The received frame is discarded and a 
FRMR is sent indicating the invalid N(R) condition. This error can only be cleared by the 
resetting of the send and receive variables at both stations. The station that receives the 
FRMR responds by the transmission of a SABM Frame. The completed SABM sequence 
clears the exceptions and re-establish the send and receive variables at bodi stations. 
Timeout Recovery 

In the event a receiving station, due to a transmission, does not receive, or receives 
and discards an I Frame or the last I Frame in a sequence of I Frames, it will not detect an 
out-of-sequence exception and therefore will not transmit a REF Frame, The station which 
transmits the unacknowledged I Frame retransmits the I frame following the Timeout period 
(2 seconds) for that frame. When a station has reached the maximum number of 
outstanding I Frames (not acknowledged), the station only retransmits the last I Frame on 
the timeout and takes the appropriate recovery action based on the response from the distant 
station. The distant station responds with an S Frame indicating the acknowledgment for 
the frames, or indicate a Busy condition, or send a REJ indicating which frames are to be 
retransmitted. Should a frame be transmitted five (5) times without an acknowledgment, 
the transmitting station shall declare a protocol failure and initiate the transmission of a 
DISC Frame. After receiving an acknowledgment for the DISC Frame or after five 
transmission of the DISC Frame without an acknowledgment, the station enters the ETM of 
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the LDS. 

Default Frame Transmission 

In the event a station does not have any I Frames to transmit, it transmits the current 
S Frame after two (2) seconds of interframe fill time. This S Frame indicates the current 
state of the station BUSY/NOT BUSY (RR/RNR), indicate the next expected I Frame 
number, and provides assurance to the distant station that the protocol and the link is 
operational. 

If a valid Frame is not received within a fifteen (15) second time period, the 
\ detecting station shall initiate disconnect procedures by the transmission of a DISC Frame. 
. The Default Frame Transmission every two seconds will reset the fifteen second timer 
' when the frame is received correctly. These procedures will detect out of synchronization 
^ in the absence of I Frame traffic. 

LAPB SYSTEM PARAMETERS 

The system parameters apply to both the DCE and the DTE. No variation shall 
exist between the two stations. The values of these parameters are fixed. The DCE and 
DTE system parameters are as follows: 

Tl TIMER 

The Tl timer is the maximum time a station waits for an acknowledgment of a 
frame transmitted before the frame is retransmitted. The value of Tl shall be 2 seconds. 
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Each frame transmitted shall be assigned a Tl timer. When the Tl timer expires for an I 
Frame, the last I frame transmitted shall be retransmitted. Also the Tl timeres for I Frames 
are halted in the event the receive station replies with an RNR S Frame indicating a busy 
condition. The Tl timers shall be resumed after the busy condition clears when the frames 
are retransmitted in order of their N(S) number. 

T2 TIMER 

The T2 timer is the amount of time a station should wait before an acknowledging 
frame is initiated for a received frame. For the IMPROVED User Data Protocol this value 
is 200 milliseconds. In the case of acknowledging an I frame, an S Frame is scheduled in 
200ms when there is no pending I Frames that can acknowledge the received frame on the 
transmit queue. If an I frame is placed on the transmit queue prior to the expiration of the 
T2 timer, then the timer is canceled. If the T2 timer is acitve, it is not restarted when 
subsequent I Frames are received. U Frames are acknowledged at the next transmission 
opportunity after reception or if required, implementation of the frame. 

T3 TIMER 

The T3 timer is a no traffic timer Its value is 15 seconds. This timer is reset upon 
the receipt of a valid frame. When the T3 timer expired link disconnect procedures are to 
be initiated by the transmission of a DISC Frame. 
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N2 MAXIMUM TRANSMISSION ATTEMPTS 

The N2 parameter indicates the maximum number of attempts to complete the 
successful transmission of a frame. The value of N2 is five (5), the original transmission 
and four (4) retransmissions. 

Nl MAXIMUM NUMBER OF BITS IN AN I FRAME 

Nl is an adjustable parameter based on the system classmarks. The default value is 
2,048 or 256 octets. This parameter must be padded to align on an octet boundary. 

K MAXIMUM NUMBER OF OUTSTANDING I FRAMES 

The value of K indicates the maximum number of sequentially numbered I Frames 
that a station may have outstanding (Not acknowledged) at any given time. For the 
IMPROVED User Data Protocol this value is seven (7), the modulus (8) minus 1. 
NETWORK LAYER PROCESSING 

The network layer provides both the Internet and Intranet routing. The Internet 
addressmg is a "built in" function of the IMPROVED User Data Protocol. The random 
access Intranet routing for half duplex (radio) interfaces shares the network layer. 

The foundation of the Network layer 3 is the Internet Header . The Internet Header 
also supports the other OSI layers of the lUDP. The network layer receives addressed 
frames from either the Transport or the Link layers. The Internet Header is initially 
examined for routing purposes. Frames which terminate at this station are passed to layer 
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4. Frames which require 

additional transmission are returned to layer 2 with a new internet header and if the 
interface is half duplex, a new Intranet Header. Further, if the net uses the Relay option, 
then a new Link Relay Header is also created. 

5 

INTERNET HEADER 

The Internet Header identifies the message, its originator, its classmarks, and its 
addresses. The Figure 26 shows a layout of the Internet Header with two addressees. The 
^1- first addressee is formatted using the basic Internet address, while the second is shown as 
10 ''f an extended addressee. The Internet Header supports up to 16 addressees. The End of 
£. Routing (EOR) bit in the addressee status byte indicates the last addressee in the header. 
m The table of Figure 27 summarizes the Internet Header Elements and the following 
Q paragraphs describes each element in the Internet Header. 

15 Fj EOM BIT 

The EOM bit is set (one) by the Transport Layer for the last Frame of a message. 

FRAME SEQUENCE NUMBER 

The Frame Sequence Number is assigned initially by the Transport Layer. Each 
20 frame of a message is sequentially numbered and the last frame is indicated by the EOM 
bit. It should be noted that message that are contained in a single frame have a sequence 
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number of one (1) and have the EOM bit set (one) indicating that its is a single frame 
message. When Transport generates multiple frames for a message, the Internet Header is 
copied (except for the EOM bit and Frame Sequence Number) into each frame. The 
Originator User-Id, Message Sequence Number, Precedence, Security, and Message 
5 Type/Protocol fields in conjunction with the Frame Sequence Number are used to identify 
the frames of a message. 

ORIGINATOR'S INTERNET ADDRESS (USER-ID) 
5} This field contains the originator's User-Id. It is used to identify the originator of 

/Pet 

10 the message and uniquely identify the frames that belong to a multi frame message. When 
4= acknowledgments or other notifications are to be returned, they are addressed to this User- 
Id. 

MESSAGE SEQUENCE NUMBER 

15 The Message Sequence Number is a number assigned by the originator. It is used to 

identify message and message frames. Transport uses this field in the reassembly of 
messages from frames. Users use this field to identify the message being acknowledged. 
The Message Sequence Number is a four (4) digit number stored in the Internet Header as 
four (4) Binary Coded Decimal (BCD) digits. 

20 

MESSAGE PRECEDENCE 
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The Message Precedence field specifies the precedence of this message. Messages 
are transmitted First In First Our (FIFO) by precedence. This field is used in conjunction 
with the net priority classification on half duplex (radio) nets. The NETCON (Network) 
precedence is restricted to SYSCON and ICMP message types. The NETCON precedence 
shall not be used with any other message types. It should be noted that SYSCON and 
ICMP message types may use lower precedence values. 

MESSAGE SECURITY 

The Message Classification field specifies the classification of the message. The 
IMPROVED User Data Protocol assumes a NETWORK HIGH classification as specified in 
the System parameters. Messages which exceed this level are not processed. They are 
' discarded and a Security Violation is reported. 



MESSAGE TYPE/PROTOCOL 

The Message Type or Protocol specifies the format and content of the data which 
follows the Internet Header. The SYSCON and Internet Control Message Protocol types 
are subsets of the IMPROVED User Data Protocol. These topics are not discussed in detail 
in this document. Refer to the applicable documents for detail formats and message 
contents. The User Defined Message type permits users of this protocol to define message 
types for their communication needs. Two values have been allocated in the User Defined 
range, these are as follows: 
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1. Message Acknowledgments, value is 41 

2. Message Non delivery Notification, value is 42. 

The Message Acknowledgment message indicates a Received, Read, and Printed 
confirmation by the recipient as requested by the originator. 

Figure 28 shows a table depicting the allocated range of message type values. 
Values not specified are reserved for future applications of the IMPROVED User Data 
Protocol. 

The Tables of Figures 29 and 30 show some specific values assigned to each 
protocol class. 

The Internet Control Messages are indicated in the Table of Figure 30. For the 
message format and content see the Internet Control Message Protocol Specification. 

The user defined message types have the following assignments as shown in Figure 
3 1 . The user may specify the remaining values within their range to provide unique 
message or protocol identification. 

Figure 32 shows the format of the User Acknowledgment message Text Header. 

The remaining User Defined Message types assigned by the implementors of this 
protocol for a given system. The User Defined types, are transparent to the internals of this 
protocol and as such provided an interoperatibility capability between systems or networks. 
The upper layers of each system resolve the differences between user groups. 

The Encapsulated protocols that have been defined are listed in the Table of Figure 

33. 
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MAXIMUM HOP COUNT 

The maximum hop count is set by the originator to limit the number of internet 
transmission (hops) of the message. This count is decremented by each internet 
transmission. When the count reaches zero, the message is discarded. This field should be 
set to minus one 

(-1) when the count is unknown. Control of the value used here may be controlled by the 
System Management. 

DESTINATION'S INTERNET ADDRESS (USER-ID) 

There are two general classes of destination addressee, the Basic or normal Internet 
Address which consists of a USER-ID, and the Extended Internet Address which consists of 
a temporary net affiliation followed by the USER-ID. USER-IDs contain two fields, a net 
identifier (NIS) and a call sign (CS). The Extended Address has a net identifier, which 
specifies the net where the addressee can be found, followed by the addressee's USER-ID. 
Figure 34 shows simple illustrations of the Basic and Extended Internet Addresses with the 
address Class Code field. 

The Class Code depicted in Figure 34 in the extended address is NOT required to be 
the same as the Class Code in the basic address. The NIS ranges up to a maximum of 14 
Bits. 

Each destination address entry in the Internet Header contains a status byte. This 
field indicates the address type (Basic or Extended), the addressee's acknowledgment 
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responsibilities, and the status of the addressee (delivered/not delivered). The Table of 
Figure 35 shows the format and content of the status byte. 

The Status bits Al, A2 & A3 of Figure 35 specify the destination End-to-End 
Acknowledgment requirements for each addressee. Each addressee is required to return 
these acknowledgments to the originator for each acknowledgment indicated when the event 
occurs. These are not link layer frame acknowledgment. 

INTERNET ADDRESSES (USER-IDS) 

The Internal address is in the form of: NIS/CS or NIS:NIS/CS which is stored in 3 
or 5 octets/bytes. The NIS is a Net Identification String and the CS is a Call Sign. This 
address is stored right justified in a 4 or 6 octet field. The Most Significant Byte is the 
address status byte. This status byte contains a indicator which specifies the number of 
address bytes that follow. The indicator is designated as the *'EXTEND" bit and when set 
(1) specifies an extended address of 5 bytes. Figures 36 and 37 depict the general format 
of these two Internet Addresses. 

In Figures 36 and 37, the XXZ is the user's original Internet Address and the YY is 
the assigned Net. The Internet Address is of^en referred to as the USER-ID. The 
IMPROVED User Data Protocol provides multiple classes of Internet Addresses, The 
general break down of the Internet address is shown in Figure 38. 

The Class Codes of Figure 38 are the two (2) most significant bits of the address 
and the values are as follows: 
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00 User Class 1 

01 Reserved 

10 Internet Equipment/Function Class 1 

1 1 Reserved 

The Class codes can be logically included in the NTS codes. The purpose of these 
classes is to extend the addressing capabilities through the use of address masks. The NIS 
has been depicted as a two (2) octet field and the call sign has been depicted as a one (1) 
octet field. Using the address class, the remaining 22 Bits of addressing can be allocated 
by the use of address mask. For example, the allocation can reassign the NIS to a single 
octet, and the call sign to a two (2) octet field. The User Class 1 address consists of 14 
bits for the NIS and eight (8) bits for the call sign, and the Internet Equipment Class 1 
address consists of 14 bits for the NIS, two (2) bits for a function code, and six (6) bits for 
the call sign. In the later case the function code can be combined with the call sign for 
routing purposes, however, the final destination can use the function bits for special 
purposes. 

Implementors of this protocol can used this classification of Internet Addresses to 
solve their communication requirements. When address masks are used to isolate the 
addressing elements, they must be defined in the System Classmarks to prevent addressing 
errors within the Network. 

The following routing description do not describe the address classes or the use of 
the address masks. These descriptions show how the NIS and Call Sign elements represent 
the routing functions of first, reaching the destination net, second, reaching the destination 
station, and finally reaching the destination process or user. 
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NETWORK LAYER 3A ROUTING 

In general, the Network Layer 3A routing examines the destination addressee(s) int 
he Internet Header and determines the disposition for that addressee by the directions found 
in the routing tables. This process determines the next action based on the protocol of the 
routing table. There are three general disposition types: 

1. Local Termination 

2. Transmission over an Access Circuit 

3. Transmission over a Half Duplex Radio Net 

Each addressee is examined to determine if the addressee is located in the home net. 
If the home net is indicated, the home net numbers routing tables are used to determine the 
disposition of the local addressee. If the addressee is not located in the home net, the 
Internet routing tables are used to find the disposition of the addressee. This disposition is 
usually to the next HOP toward the destination net. If the net is not found in the table, one 
of two options are available: 

1. Send the frame with the addressee to a default Exit Point or Router 

2. Discard that addressee as an invalid address 

The entry for each address argument in the routing table should indicate the 
following: 

1. Channel/Port number when this route requires an access circuit transmission. 

2. Station Address/Port number when this route requires a radio net 
transmission. 
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3. An interface protocol procedure or queue when this route terminates at this 
station. 

The Channel/Port number indicates a transmission queue for an interface to another 
switching node. That switching node shall repeat the routing process for all the 
addressee(s) routed there. The routing process sorts the addressee by disposition class and 
port, builds a new Internet Header with only those addressee(s) which are to be transmitted 
over that port. 

The Station Address/Port number indicates the port and the station address/number 
to be added to the Intranet Header. Again only the addressee(s) for that port shall be 
placed in a new Internet Header in addition to the addressee's station number being placed 
in the Intranet header. 

The interface protocol procedure or designated queue is for the application 
processing of the message at the local destination. Again only those addressee(s) with the 
same disposition is placed in the new Internet Header prior to the execution of the protocol 
procedure or the enqueuing of the message to the specified queue. Detail demultiplexing of 
messages by the Message Type/Protocol field shall be the responsibility of the initial 
application or Transport Layer. 

NETWORK LAYER 3B ROUTING 

The Network Layer 3B only applies to half duplex "Relay" nets. The network 
Layer 3B uses the Intranet Header generated by the Network Layer 3 A to generate the Link 
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Layer Header which contains a list of destination and/or relay stations. As an independent 
and optional feature, this layer and its related protocols are presented in Reference 1, 
Intranet Packet Relay Protocol Specification. 

NETWORK CONGESTION CONTROL 

Network congestion is monitored by the net controllers. When data activities exceed 
a threshold, the net controller sends a Net Congestion Control Notification (NCCN) to all 
net members. The NCCN is an I Frame which request the restriction of low precedence 
traffic, to one, reduce the amount of Intranet traffic, and two, to insure enough bandwidth 
for high precedence traffic. 

Internet congestion is monitored by the Internet nodes, BICCs and Gateways. When 
an Internet node becomes congested it sends a Link Congested Control Notification 
(LCCN) to the members of one or more connected nets restricting low precedence Internet 
traffic. The LCCN reduces Intranet traffic by reducing the amount of traffic sent to one, 
the Internet Routers by individual stations, and two, by reducing the traffic loads between 
the Internet Routers and Internet Switching Nodes. 

These and other congestion controls are described in more detail in the paragraphs 

below. 

STATION CONGESTION CONTROL 

The lUDP provides the ability for every station to restrict the receipt of data traffic 
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(I Frames) through the use of Receiver Ready and Receiver Not Ready supervisory frames. 

Congestion normally occurs when buffer or queue resources are almost exhausted. 
This event causes a station to enter the Busy mode or condition, as it can no longer accept 
data traffic. When the station declares the Busy condition by the transmission of the RNR, 
it does not accept any additional I Frames. When an I Frame is received while in the Busy 
condition, the station reinforces its Busy condition by the transmission of another RNR. 
The RNR has the Global address for Half Duplex interfaces. Additional congestion 
controls are described in the paragraphs below. 

HALF DUPLEX INTERFACES 

The Half Duplex Interfaces have, in addition to the S Frames, the Frame Type field 
which specified the station's mode Busy/Not Busy. The Frame Type makes it possible to 
indicate the originating station's condition without the repeated transmission of an S Frame. 
S Frame Commands which indicate a station's mode use the global address. Use of a 
specific address only effects the addressed station and Not the other stations on the Net. 

FULL DUPLEX INTERFACES 

The Full Duplex interface only uses the Receiver Ready and Receiver Not Ready 
supervisory frames. It should be noted that the N(R) does acknowledge frames up to N(R)- 
1 in both the RR and RNR frames. The Busy condition can be cleared with a REJ S Frame 
or a mode setting U Frame. The best way to clear the busy condition is by the 

- 74 - 



D-ACD.E025 

transmission of the RR S Frame, as the other methods require additional time with the 
possibility of lost data due to the clearing of queue as in the case of the SABM or DM U 
Frame. 

LINK/NET CONGESTION CONTROLS 

The Net Controller can regulate the amount of data traffic on a link/net to reduce 
congestion and insure the success of high precedence traffic with the transmission of a Net 
Congestion Control Notification (NCCN). The NCCN is an I Frame addressed to various 
members of the Link/Net restricting routine and priority precedence traffic. The Net 
Controller determines the utilization of the Link/Net and makes either an automated or 
command decision. Destinations which receive a NCCN shall lock or unlock the specified 
precedence queue. 

INTERNET NODE CONGESTION CONTROLS 

Internet nodes (BICC & Gateway) have the same link layer congestion control 
procedures as any other station. They can use the lijik layer S Frames, Receiver Ready & 
Receiver Not Ready, to regulate the input traffic for processing. 

Internet nodes use a flow control scheme to regulate the types of input traffic being 
transmitted through it. This scheme uses a Link Congestion Control Notification (LCCN). 
The LCCN is an Information Frame which regulates the traffic by precedence. The LCCN 
restricts the lowest precedence Internet traffic first. If congestion is not relieved the next 
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precedence level Internet traffic is restricted. The highest precedence level traffic is Not 
restricted by LCCNs, this precedence is only restricted by the link layer S Frame, which 
stops all traffic. 

The Interent node sends a LCCN to restrict routing Internet traffic when its resource 
utilization is greater than 60% and sends a LCCN to resume routing Internet traffic when 
the utilization falls below 55%. The priority Internet traffic is restricted at 70% and resume 
at 64% or lower. Flash Internet traffic is not restricted by the LCCN. It is noted that the 
LCCN does not restrict traffic that is addressed to Users attached to the Interent Node, or 
traffic which is addressed to the Node functions. 

INTERNET CONTROL MESSAGE PROTOCOL (ICMP) 

This is a comprehensive description of the Internet Control Message Protocol 
(ICMP). The ICMP manages and supports Internet communications. The protocol exists in 
the User Data Terminals (UDT), the Basic Interent Control Cards (BICC) applique, and the 
CIS Gateways. The MIS uses the SYSCON Message Protocol for its management of the 
system. 

The ICMP operates over all communication links. The ICMP is a Network Layer 
(Layer three) function, and is independent of the Link and Physical Layers. The ICMP is 
the means by which the Internet regulates congestion, informs peer processes of changes in 
the Internet, and performs "Network Management" of the Internet. 
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INTERNET CONTROL MESSAGE PROTOCOL REQUIREMENTS 

The Interent Control Message Protocol (ICMP) requires the use of the IMPROVED 
User Data Protocol Internet Header. The descriptions used below are limited to the fields 
and functions used by the ICMP. The ICMP uses the Message Type/Protocol field to 
define its message types. Each ICMP Message is described with its format and content. 

The ICMP extends the service of the lUDP Internet. This service includes, Error 
notification, Status reports, Adaptive Internet Routing and Internet Routing Update 
messages, Internet Congestion Control, and Internet Enquiry/Response messages. 

Figure 39 specifies the ICMP Messages using the Message Type/Protocol values. 
Each message is presented it the paragraphs below. 

^ TRANSPORT ACKNOWLEDGMENT MESSAGE 

The Transport Acknowledgment is created by the Destination Transport Control 
specifying the received frames of a multiple frame message. The message is addressed to 
the Originating Transport Control Process. This message is created when, all the frames of 
a multiple firame message are received, or after a timeout occurs after receiving some 
fi-ames of a multiple frame message. The Originating Transport Control Process will re- 
transmit those frames not acknowledged in the acknowledgment message. 

The Table of Figure 40 specifies the message format and contents of the Transport 
Acknowledgment Message. The Acknowledgment message is variable in size and 
immediately follows the Internet Header. The Interent Header of the Transport 
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Acknowledgment message is built from the data extracted from the message's Internet 
Header. The fields that are used are specified below. 

ORIGINAL MESSAGE ACKNOWLEDGMENT MESSAGE 

Originators Address Destination Address 

Message Serial Number Message Serial Number 

Message Precedence Message Precedence 

The Following Internet Header Fields in the acknowledgment message are set as 
follows: 

L Security set to UNCLASS 

2. Originator Address set to the first Address in the body of the 
Acknowledgment message 

3. Message Type/Protocol set to "01" 



LINK CONGESTION CONTROL NOTIFICATION (LCCN) 

The LCCN message is generated by Internet Routers and Internet Points when 
congestion thresholds are crossed. The LCCN restricts/reinstated Internet traffic by specific 
message precedence values. The message uses a boolean indicator for each precedence 
level. When the boolean is "True" the precedence is restricted, when the boolean is 
"FALSE'' the restriction is lifted. Figure 41 specifies the LCCN text. The Internet 
Router/Point is identified by the originator's Internet Address. The destination address uses 
the "ALL" or Broadcast address. 
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when insufficient traffic is present to determine the operational status of the Internet Node, 
This message is normally sent by the Net Controller. The message can be generated either 
on demand or automatically on an event basis. The query message is a Header only 
message addressed to one or more Internet Routers/Points. Each recipient shall respond to 
the originator of the query message with a LCCN, specifying its status. The lack of any 
response in an "All Informed" net shall indicate a Failed Internet Node. 

Retries of the query message can be attempted to resolve this issue in a "Relay" net 
where link layer acknowledgments are not received by the originator. 

INTERNET STATUS REPORT MESSAGE 

There are two basic Statue Reports that are provided by the Internet Nodes, the 
Node Status Report and the Internet Route Report, The Node Status Report provides the 
following information: 

1. Number of message frames transmitted and Received 

2. The average and peak number of frames in the transmit queue 

3. The percentage of net usage (Net in use voice & data) 

The Interent Route Report specified the usage of internet routes. This includes the 
number of times each route has been used. 

The Status Report is sent either upon request or under Alarm condition. The Alarm 
condition is activated when established thresholds are exceeded. Figures 43 and 44 show 
the table of conditions for REPORT TEXT & HEADER. 
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INTERNET STATUS REPORT FORMAT 

The Internet Status Report is generated by Internet Nodes and reflect status data for 
each internet interface. The Internet Header indicated the originating node, while the text 
of the report indicates each internet interface and the status data based on its perspective. 

The TABLE format of Figure 45 uses a two (2) net report as an example. Nodes 
which interface to more than two nets use the same format. The text just contains more 
than two entries. 

INTERNET ROUTE REPORT FORMAT 

The Internet Route Report contains a list of the nets (NIS'), a usage flag, and a count 
of the number of frames that were addressed to that NIS. This report is requested and 
provides management with internet traffic patterns. Unused internet routes can be removed 
and heavily used routes can be provided with alternate routes. Figure 46 shows a TABLE 
depicting the ROUTE REPORT TEXT. 

USER REGISTRATION MESSAGES 

The User Registration messages are exchanged between Net Controllers and the CIS 
Gateway and the Net Controller and the Net Members. When a user moves into a net and 
registers (voice contact) with Net Controller the Net Controller adds the User to the Net 
Members List, distributes the addition to the net members and sends the User Registration 
message to the Gateway. 
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The Gateway upon receipt of the User Registration message attempts to update the 
User's Home Net, and if the user was already in another net, de-register the user. The 
Gateway finds the user's User-Id in its "Home" net members list, extract an existing Out-of- 
Net NIS if present. The Gateway updates its copy of the Net Members List, and forwards 
a Change User Registration message to the home net specifying the New Out-of-Net NIS. 
If the user was in another net, the Gateway forwards a De-registration Message to the Net 
Controller of the previous Out-of-Net NIS. Each Net Controller updates the Net Members 
List and distributes the change using the appropriate Registration message. 

The three registration message types are: Register, De-register, and Change 
Registration. Table 41 shows the FIELDS VALUE/RANGE & DESCRIPTION OF THE 
REGISTRATION TEXT HEADER. 

After a user registers in a net, the Net Controller updates/loads the net's data base to 
the user using the SYSCON message protocol. 

SYSTEM CONTROL (SYSCON) MESSAGE PROTOCOL 

This is a functional description of the System Control (SYSCON) Message Protocol. 
The SYSCON supports Internet communications. The protocol exist in the User Data 
Terminals (UDT), the BASIC Internet Control Cards (BICC) applique, the CIS Gateways 
and the MIS Terminals. SYSCON is considered to be an application layer function; 
however, because the Internet layers generate SYSCON message, the basic formats and 
structures are defined in this document. The Internet uses the SYSCON Message protocol 
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to report events and Internet conditions to the MIS manager. This description does not 
attempt to define the detail messages, or processing procedures for SYSCON. This 
description does define the functional message types and the overall format for SYSCON 
messages without specific implementation details. 

All SYSCON messages interface with the Internet through the Transport Layer. The 
Internet event handlers that generate SYSCON messages shall envoke the Transport Layer 
to introduce the SYSCON message in to the network. It should be noted that while the 

Jntemet generates SYSCON messages, it is not a target or destination of SYSCON 
messages. The Internet uses the ICMP for peer to peer communication. 

J The SYSCON Message Protocol is an application which uses the IMPROVED User 

1 Data Protocol as its communication link between the controlling entity and the functions 
which receive and process the SYSCON messages. SYSCON shall interface through the 

" lUDP through the Transport Layer and shall be independent of the Link and Physical 

^ layers. 

SYSCON MESSAGE PROTOCOL REQUIREMENTS 

The SYSCON Message Protocol requires the use of the IMPROVED User Data 
Protocol Internet Header. The Internet Header is described later. The descriptions used 
below are limited to the fields and functions used by the SYSCON Messages. The 
SYSCON uses the Message Type/Protocol field to define its message types. The SYSCON 
message is the interface for the administration and control of the communication system, 
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and the reporting of events and conditions by the Internet to the MIS. The SYSCOM 
message service includes, Table and Data Base management, including initial data base 
loading, Error Notification, Status Reports, Non-Adaptive Routing and Routing Override 
Table Update messages, and Enquiry/Response messages. 

Figure 48 depicts a table which specifies the SYSCON Message types using the 
Message Type/Protocol values. Each message class contains its own messages which shall 
be defined for each implementation. 

' SYSCON DIRECTIVES 

Figxire 49 is a TABLE which specifies the format of the Text Header for SYSCON 
directives and Figure 50 defines the Directive text format, SYSCON processing uses the 
originator address, message precedence, message serial number, and destination address 
fields of the Internet Header. These fields are used to qualify and validate the message. 
SYSCON Directives can use any of the precedence levels. The precedence should be 
selected based on the urgency of the directive. 

SYSCON ALARMS & NOTIFICATIONS 

Figure 51 is a Table which specifies the format of the SYSCON Alarm & 
Notification Text Header and Figure 52 is a Table which defines the Alarm & Notification 
Text Format. SYSCON processing establishes the originator address, message precedence, 
and destination address(s) in the Internet Header. Alarms should use the Network 
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Precedence level, while notifications should use the lower precedence levels. 

Figure 53 is a Table which specifies the format of the SYSCON Report Text Header 
and Figure 54 defines the Report Text Format. SYSCON processing establishes the 
originator address, message precedence, and destination address(s) in the Internet Header. 
Reports should NOT use the Network Precedence level. 

SYSCON ACKNOWLEDGMENTS 

Figure 55 is a Table which specifies the SYSCON Acknowledgment Text Header. 
If the acknowledgment specifies Not Implemented, then the Acknowledgment Text is 
required as a specified in Figure 56. The Acknowledgment Message shall use the same 
precedence level found in the Directive. The destination is set to the originator of the 
directive and the Message Sequence Number shall be the same as that used in the directive. 

ORIGINATION TRANSPORT CONTROL 

The transport control accepts an Internet Header and message text. If the text 
portion exceeds the frame size specified in the System Classmarks, then muUiple frames are 
created using the Internet Header in each frame along with up to the specified number of 
bytes of text. This process continues until the input text is completely processed. 

These frames are passed to Network Layer (layer 3) for routing and output into the 
network. A table is built for each addressee in the message and a timer is started. This 
timer is set for a wait time for the peer transport control to acknowledge ALL the frames of 
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this message. When the timer expires the frames NOT acknowledged are then retransmitted 
through layer 3. At this time the transport control window contains ALL message frames. 

The timeout period and the maximum number of retransmissions are established in 
the System Classmarks. 

DESTINATION TRANSPORT CONTROL 

The transport control accepts message frames from layer 3. A table is built for each 
originator/message serial number combination. A timer is started to time the wait period 
for all the frames. This timer is the maximum wait time as the total number of frames is 
not known until the last frame has been received. The timer value is defined in the System 
Classmarks. 

The frames are accumulated and sorted by frame number. When all the frames are 
received an acknowledgment message is sent to the peer process at the originating User-Id. 
If the timer expires prior to receiving all the frames, an acknowledgment is sent to those 
frames that have been received, and a new timer is started. The peer process should 
retransmit those frames not in the acknowledgment. If the timer expires again without 
receiving any of the missing frames, the accumulated data is discarded and a receive log 
entry is created indicating that an aborted process has occurred. If additional frames are 
received the process continues until either a complete message is received or an abort 
timeout occurs. 

Completed messages are reassembled into a single unit consisting of an Internet 
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Header and the message text. This complete message is then passed to the application 
using the Message Type/Protocol field, 

TRANSPORT ACKNOWLEDGMENT MESSAGE 

The ICMP message was described above and functions as the transport 
acknowledgment message. 

PRESENTATION LAYER PROCESSING 

The presentation layer accept addressing data and message text from the 
user/application layer. The addressing data, if symbolic in nature is converted to internal 
encoding and merged with other message classmarks such as precedence, security, and 
message types. 

The presentation layer provides a system service of extending the Internet Header 
with Global Positioning System data, if present, for its peer process at the destinations. If 
the peer process accumulates position data, this information is extracted for the positioning 
"module". If the peer process does not accumulate positioning data, then the data is 
ignored. In either case the actual text of the message is passed to the application. 

PRESENTATION LAYER PROCESSING 

The presentation layer accept addressing data and message text from the 
user/application layer. The addressing data, if symbolic in nature is converted to internal 
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encoding and merged with other message classmarks such as precedence, security, and 
message types. 

The presentation layer provides a system services of extending the Internet Header 
with Global Positioning System data, if present, for its peer process at the destinations. If 
the peer process accumulates position data, this information is extracted for the positioning 
"module". If the peer process does not accumulate positioning data, then the data is 
ignored. In either case the actual text of the message is passed to the application. 

This GPS data is extracted from the application data base when present and is stored 
j in the GPS Field of the Layer 6 Internet Header. The GPS Field follows the last 
^ destination addressee in User Defined message types. The GPS Data is variable and the 

I format is specified by the GPS Flag. The GPS Flag specifies the type, size, and format of 

I 

' the GPS data. The GPS FLAG indicates one of the following: 

1. NONE There is no GPS data 

2. TYPE 1 = Latitude/Longitude (Degrees, Minutes & Seconds) 

3. TYPE 2 = Latitude/longitude (Degrees & Minutes) 

4. TYPE 3 = Universal Transverse Mercator (UTM) 

5. TYPE 4 = Military Grid Reference System (MGRS) 

Figure 57 depicts the Internet Header with respect to the Presentation Layer (Layer 
6) and the lower Internet layers (Layers 4, 3, & 2). It should be noted that the figure 
depicts an Internet Header for a User Defined Message, that is the message type/protocol 
field is within the range of 41 through 60. System Control (SYSCON) and Internet Control 
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Message Protocol (ICMP) do NOT contain the GPS Field. 

This Presentation process builds the Internet Header, the Global Positioning System 
data, and combines them with the specified text into a contiguous data unit which is passed 
to Transport Layer. It should be noted that if the Transport Layer segments the message 
into multiple frames, the GPS Field is not copied into every frame. The transport treats the 
GPS as message text. 

The Transport layer passes received messages to a presentation layer based on the 
Message Type/Protocol disposition specified in the routing tables. The presentation layer 
t shall have final disposition of the message to the user application layers. 

SYSTEM CONTROL (SYSCON) APPLICATIONS 

The SYSCON applications performs du-ective execution and acknowledgment, report 
generation, Inquiry and Response processing. These application module interface with the 
Transport Layer. SYSCON applications provide the Network management in conjunction 
.. with the operator, the MIS and the Network Layer Internet Control Message Protocol. The 
SYSCON applications also interface with the Man/Machine Interface modules on systems 
that have operator positions. 
X.21 HALF DUPLEX PHYSICAL LAYER 

This Physical layer is a half duplex variation of an X.21 point-to-point connection. 
The "C" circuit of X.21 is a transmit request (PTT) from the DTE to the Radio (DCE). 
The "I" circuit of X.21 is a "BUSY" indicator from the radio (DCE) to the DTE. This 
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"BUSY" indicator may indicate receive data. When there is data for the DTE the radio 
provides CLOCK to the DTE which brings in the data. When the data transfer to the DTE 
is complete, both the "I" and CLOCKS will be disabled. If CLOCKS never occur while 
the "I" is enabled, the radio is BUSY processing VOICE or is NOT Available/Present. 

Figure 58 shows a state chart of a Half duplex interface between two DCES or radio 
85 and 86 and communicating interfacing with DTEs. 

X.21 FULL DUPLEX PHYSICAL LAYER 

The X.21 full duplex physical layer shall be a full duplex point-to-point circuit. 
I This circuit can operator at either 16KBPS or 32KBPS, and the DCE shall provide clock 
i for both the transmit and receive data. The "C" and "I" circuits are used to indicate the 
i presence of DTE and DCE respectively. 

The state chart of Figure 59 depicts the Full Duplex X.21 interface between two 

Stations (DCE/DTE). 

EXAMPLES OF PROTOCOL ENCAPSULATION 
ENCAPSULATION OF X.25 PACKETS 

Figure 61 shows an encapsulated X.25 Packet. 
ASYNCHRONOUS PHYSICAL LAYER 

The Asynchronous Physical Layer is a full duplex, eight (8) bit characters, with or 
without parity, operating in a range of 1,200 to 9,600 BPS. Every asynchronous 
transmission is proceeded with the asynchronous preamble of "SYN SYN SI XXXX CR", 
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where: 

SYN is the ASCII Sync character 

SI is the ASCII SI Character 

XXXX is the number of Bytes/Octets in four (4) ASCII Numeric Characters. This is 
the number of Octets in the link layer frame. The Valid range of XXXX is 
two (0002) through Maximum Frame size as established in the System 
Classmarks. 

CR is the ASCII Carriage Return Character. 

The link layer frame follows the carriage return. This includes the frame Address, 
Control, & Information fields. It should be noted that both the Full Duplex and the Half 
Duplex Point-to-Point Link Layers can be carried by this Physical layer. The Frame Check 
Sequence for the asynchronous layer is Not used. The Link layer frame is followed by the 
asynchronous checksum. This checksum is a two (2) octet field which contains the addition 
of all the octets in the Link layer frame. 

It should be noted that this interface requires two (2) SYN characters, additional 
SYN characters are ignored. The following Figure depicts the Asynchronous transmission 
format. Each subfield in the preamble is 1 octet (ASCII Character) with the character 
parity bit being ignored. The value of XXXX is the decimal number of octets in the link 
layer frame. The sub fields of the link layer frame are as specified in the other Full Duplex 
frame formats, with the exception of the FCS as described above. Figure 60 is a table 
showing asynchronous transmission. 



ENCAPSULATION OF X,25 PACKETS 
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Figure 61 shows an encapsulated X.25 Packet. 

The X.25 General Format Identifier specifies the X.25 Packet Type. The Types are 
listed below: 

Call Set-up Packets 

Clearing, flow control, interrupt, reset, restart, registration and diagnostic packets 
Data Packets 

The individual packet types are specified by the "Packet Type Identifier" in the X.25 
Header. The X.25 packet level is well known and well documented. 
Figure 62 shows the encapsulation of an IP Packet. 

Figure 63 shows the encapsulation of a TCP header followed by its upper layer data. 
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